generating sealer keystore by hand

[Cantor, Scott]

On 5/7/15, 1:57 PM, "Scott Koranda" <skoranda at gmail.com> wrote:
>
>I understand the keystore to be of type JCEKS and the key to be AES.

Yes, the code is written to use an AEAD algorithm to avoid having to separately MAC and encrypt, and AES-GCM is the only such algorithm available to us.

>Am I correct that a key length of 256 and an alias of 'secret1' (since
>the initial version number starts counting at 1) generated with this
>command
>
>keytool -genseckey -keystore sealer.jks -storetype jceks -storepass
>PASSWORD -keyalg AES -keysize 256 -alias secret1 -keypass PASSWORD
>
>is sufficient for use by the v3 IdP?

Technically the whole management of keys and their aliases and all that is factored out so you could override it, but the default implementation uses the alias property plus the key version number to construct the keystore alias, that's where the "secret1" comes from.

I think the key size used is actually 128 bit, so 256 works, it's probably just ignoring half of it. AES-128 is faster than AES-256 and hasn't lost any rounds to attack, so it's the suggested AES choice for general use right now.

Is there a reason not to just call the seckeygen script/utility to do that same thing? That's not Ant, it's just a Java class. The idea was that using that API would be more insulating and let us make adjustments that wouldn't break anybody.

>Do you consider these details to be a "public API" of sorts that will
>not change (much) going forward, or is relying on the IdP installation
>process to create the key and keystore the only supported mechanism?

I would not say that any particular use of keytool is a supported method, whereas using the BasicKeyStoreKeyStrategyTool (which is what the script calls) to do the same thing is.

I think we would not necessarily guarantee that the internal strategy bean used wouldn't be swapped out if we had a reason to. Not in a patch probably, but in a minor rev maybe. The bean itself is hidden now, so it's changeable. But the API of that bean itself is in a public API package, so we wouldn't change that interface itself incompatibly. Subtle distinction I guess, but it's there.

Of course, if we did any of that, it would have to "just work" and be able to handle the keystores and version files in the field and probably have to work with people using the provided examples to maintain the key, so this is all pretty hypothetical, but the use case I had in mind eventually was to use the newer Java 8 keystore APIs and hopefully get rid of the extra version file. But I can't do that any time soon.

Anyway, I guess the answer is, using the bean provided as a command line tool is definitely supported, but not using keytool directly. For one thing, having only the keystore won't work, it needs the version file too.

-- Scott