This looks good. Just a few comments:
- please add a release note subtask and open a separate docs issue to
document the new etypes
- does this need a CSR? I would think it does because it is adding
support for a new RFC and etypes
* AesSha2DkCrypto.java
- why does stringToKey(char[] password, String salt, byte[] s2kparams)
swallow exceptions but stringToKey(char[] secret, byte[] salt, byte[]
params) does not?
- can you verify if the new proposed KDF API could be used for the
key-derivation parts in the future?
--Sean
On 11/1/17 8:38 PM, Weijun Wang wrote:
Ping again.
On Sep 18, 2017, at 5:15 PM, Weijun Wang <weijun.w...@oracle.com> wrote:
Hi All
Please take a review at
http://cr.openjdk.java.net/~weijun/8014628/webrev.00/
Most changes are just duplicating existing classes/methods/fields on AES-SHA1
etypes. One day we might do some refactoring to simplify this.
Real changes:
- AesSha2DkCrypto.java:
1. A new dr() method, explained in https://tools.ietf.org/html/rfc8009#section-3
2. etype name used in stringToKey(), explained in
https://tools.ietf.org/html/rfc8009#section-4
3. A separate deriveKey() method. Not only it reduces duplicated codes, but it
is also used in KerberosAesSha2.java the test.
- Config.java:
Previous AES-SHA1 etypes now have aliases aes128-sha1 and aes256-sha1.
- EType.java:
The default enctypes set now includes the new aes-sha2 etypes, but aes-sha1
etypes are more preferred. This is also what MIT krb5 is doing.
- KerberosAesSha2.java
Test vectors in https://tools.ietf.org/html/rfc8009#appendix-A.
Thanks
Max
