Extends the API with SecretKey types in addition to raw byte[] #5
Conversation
This is to make the lib compatible to security framework that require the use of the JCE to work properly (e.g. HSM front ends). Breaks the hkdfMacFactory interface. refs #4
| * <p> | ||
| * See {@link #expand(byte[], byte[], int)} for description. | ||
| * | ||
| * @param pseudoRandomKey a pseudo random key of at least hmac hash length in bytes (usually, the output from the extract step) |
There was a problem hiding this comment.
But if you have byte[] returned from extract step, you would need to create a SecretKey out of it, right?
There was a problem hiding this comment.
Correct - however this does not seem intuitive I believe it makes sense. The expand returns a piece of entropy which always will be a byte array known to the JVM when using this lib (the output of a HMAC basically).
The extract API using the SecretKey type is a special use case (I just wanted to include it to make the API complete), most times the extract will be used with the byte[] API even when using a HSM.
| * @return new byte array of output keying material (OKM) | ||
| */ | ||
| public byte[] extractAndExpand(SecretKey saltExtract, byte[] inputKeyingMaterial, byte[] infoExpand, int outLengthByte) { | ||
| return new Expander(macFactory).execute(macFactory.createSecretKey( |
There was a problem hiding this comment.
This answers my above question: yes, you use macFactory to wrap the byte[] into SecretKey
There was a problem hiding this comment.
Yes, but you can still use the old byte[] API
| @@ -190,9 +235,9 @@ HkdfMacFactory getMacFactory() { | |||
| * if not provided, it is set to a array of hash length of zeros. | |||
There was a problem hiding this comment.
I believe the "if not provided" line is about the salt and not the IKM
There was a problem hiding this comment.
True, this is a doc bug.
|
|
||
| @Override | ||
| public SecretKey createSecretKey(byte[] rawKeyMaterial) { | ||
| if (rawKeyMaterial == null || rawKeyMaterial.length <= 0) { |
There was a problem hiding this comment.
I think rawKeyMaterial.length == 0 should be sufficient
Edit: also, don't you want an IllegalArgumentException to fail hard and fast? I don't think anyone wants to supply or get a null when going for a secret key.
Edit 2: ah, I see it is applied to the salt, which can be null. Ok, makes sense to me now.
There was a problem hiding this comment.
Yes. Altough I would also prefer a fail fast, null is an option here.
Fix spelling in docs
This is to make the lib compatible to security framework that require
the use of the JCE to work properly (e.g. HSM front ends).
Breaks the hkdfMacFactory interface.
refs #4