-
Notifications
You must be signed in to change notification settings - Fork 56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ConcatinationKDF: SSKDF from NIST.SP.800-56Cr2 Key Derivation #397
Conversation
* The following algorithms for SecretKeyFactory are added for non-FIPS builds: * ConcatenationKdfWithSHA224 * ConcatenationKdfWithSHA256 * ConcatenationKdfWithSHA384 * ConcatenationKdfWithSHA512 * ConcatenationKdfWithHmacSHA256 * ConcatenationKdfWithHmacSHA512
src/com/amazon/corretto/crypto/provider/ConcatenationKdfSpi.java
Outdated
Show resolved
Hide resolved
throw new IllegalArgumentException("Output size must be greater than zero."); | ||
} | ||
this.outputLen = outputLen; | ||
this.algorithmName = Objects.requireNonNull(algorithmName); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should you validate the algorithmName here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The KDFs are used in different context. It's hard to come up with the exhaustive list of all acceptable algorithm names.
throw new IllegalArgumentException("Secret must be byte array with non-zero length."); | ||
} | ||
this.info = Objects.requireNonNull(info); | ||
this.salt = Optional.ofNullable(salt); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the salt is provided, it should be non-zero as well.
Validate the constraint documented above "When using HMAC variants, a salt must be provided."
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I simplified the logic so that salt is never null. In case it's not provided, an empty array is used. The same goes for info.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm with nits
* <p>If info or salt is not provided, empty byte arrays are used. | ||
* | ||
* <p>The algorithmName is the name of algorithm used to create SecretKeySpec. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* <p>If info or salt is not provided, empty byte arrays are used. | |
* | |
* <p>The algorithmName is the name of algorithm used to create SecretKeySpec. | |
* <p>If info or salt is not provided, empty byte arrays are used.</p> | |
* | |
* <p>The algorithmName is the name of algorithm used to create SecretKeySpec.</p> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Turns out this is unnecessary in a java docstring, and the linter will even remove the close tags. 🤦
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, only request is to remove SHA224 support unless there is a hard requirement for it.
Description of changes:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.