So here's a first cut at what it would take to move this to security.json (hey, it compiles, but it's completely untested).
The reason I'm putting this up is that putting this value in security.json starts to get...messy and I'm wondering if the elegance of putting this in security.json outweighs the messiness.
The basic problem is that CryptoKeys doesn't have access to SecurityConfig. So we can either pass CoreContainer down to CryptoKeys (yuuuuck, talk about architectural badness) or have CryptoKeys take a length for this buffer.
The second option requires that the caller get the new value from the SecurityConfig object if it's different than the default and pass that in to the c'tor. Which I made the PKIAuthenticationPlugin do.
Unless we make the default CryptoKeys c'tor private, any new classes using CryptoKeys has to remember to get the value from security.json which could be forgotten. I suppose we can just deprecate the default c'tor and then caveat emptor. My guess is that just making the default c'tor private is unacceptable as it breaks back-compat.
All this to allow different buffer lengths to be chosen. So is it really worth it? It seems we have several options:
1> go ahead and put it in security.json because it's the right thing to do.
2> allow it to be configurable with a sysvar, which is much easier.
3> hard code it to some future-friendly value like 4096. This assumes that having a value larger than necessary is OK.
Or am I missing some way to get around this mess?
P.S. there's a nocommit in there (should we really have a main method in CryptoKeys?) and I'll take out a change in the PKI test unless we deprecate the default c'tor in CryptoKeys if we decide to put this in security.json after all.