On 12/19/2017 07:52 AM, Weijun Wang wrote:
On Dec 19, 2017, at 10:05 PM, Sean Mullan <sean.mul...@oracle.com> wrote:
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
Will do.
* AesSha2DkCrypto.java
- why does stringToKey(char[] password, String salt, byte[] s2kparams) swallow
exceptions but stringToKey(char[] secret, byte[] salt, byte[] params) does not?
I simply copy the behavior of the same methods for other etypes. Looks like the
later is always private and called by the former. The former is called by
EncryptionKey::acquireSecretKey and this method was designed to accept a null
value instead of handle an exception.
- can you verify if the new proposed KDF API could be used for the
key-derivation parts in the future?
I'll try.
I took a quick look at the dr() method and I'm pretty sure this can fit
into the KDF API as it currently sits. I'd like to read that section of
the RFC just to be sure, but it looks pretty straightforward. Out of
curiosity does this KDF get used anywhere other than Kerberos?
Thanks
Max
--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
