Counter KDF: NIST SP 800-108r1-upd1 #399
Conversation
amirhosv
force-pushed
the
cntrkdf
branch
5 times, most recently
from
39dc35c
to
65892ec
Compare
| public CounterKdfSpec( | ||
| final byte[] secret, final byte[] info, final int outputLen, final String algorithName) { | ||
| this.secret = Objects.requireNonNull(secret); | ||
| if (this.secret.length == 0) { |
There was a problem hiding this comment.
From a cryptographic perspective, should we really be letting people have 1-byte KDK's? This seems like an unnecessary footgun. FWIW, I did look at the AWS-LC source and they also only check that this is non-zero. So if we follow the principal of not adding any new semantics in ACCP this should stay (but I feel gross about it).
There was a problem hiding this comment.
From the library perspective, I think the right approach is to implement the standard faithfully.
| @@ -0,0 +1,802 @@ | |||
| [TEST] | |||
|
|
|||
| HASH=SHA1 | |||
There was a problem hiding this comment.
You've imported KATs for SHA1 KDFs but we do not support this.
There was a problem hiding this comment.
The file has been copy-pasted from AWS-LC's repo. In case we have to add SHA1 in future, then there do not have to change this file.
|
|
||
| // The rest of the tests are only available in non-FIPS mode. | ||
| @Test | ||
| public void concatenationKdfExpectsConcatenationKdfSpecAsKeySpec() throws Exception { |
There was a problem hiding this comment.
should this be counterKdfExpectsCounterKdfSpecAsKeySpec? we're requesting a Counter KDF factory and asserting that it doesn't accept a PBEKeySpec
Description of changes:
The following algorithm for SecretKeyFactory are added:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.