RFR 8014628: Support AES Encryption with HMAC-SHA2 for Kerberos 5

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

RFR 8014628: Support AES Encryption with HMAC-SHA2 for Kerberos 5

Weijun Wang
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

Reply | Threaded
Open this post in threaded view
|

Re: RFR 8014628: Support AES Encryption with HMAC-SHA2 for Kerberos 5

Weijun Wang
Ping again.

> On Sep 18, 2017, at 5:15 PM, Weijun Wang <[hidden email]> 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
>

Reply | Threaded
Open this post in threaded view
|

Re: RFR 8014628: Support AES Encryption with HMAC-SHA2 for Kerberos 5

Sean Mullan
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 <[hidden email]> 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
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: RFR 8014628: Support AES Encryption with HMAC-SHA2 for Kerberos 5

Weijun Wang


> On Dec 19, 2017, at 10:05 PM, Sean Mullan <[hidden email]> 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.

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 <[hidden email]> 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
>>>

Reply | Threaded
Open this post in threaded view
|

Re: RFR 8014628: Support AES Encryption with HMAC-SHA2 for Kerberos 5

Jamil Nimeh


On 12/19/2017 07:52 AM, Weijun Wang wrote:

>
>> On Dec 19, 2017, at 10:05 PM, Sean Mullan <[hidden email]> 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 <[hidden email]> 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
>>>>

Reply | Threaded
Open this post in threaded view
|

Re: RFR 8014628: Support AES Encryption with HMAC-SHA2 for Kerberos 5

Sean Mullan
In reply to this post by Weijun Wang
On 12/19/17 10:52 AM, Weijun Wang wrote:
>> * 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.
>

Ok, I suggest logging the exception if debug is enabled.

--Sean
Reply | Threaded
Open this post in threaded view
|

Re: RFR 8014628: Support AES Encryption with HMAC-SHA2 for Kerberos 5

Weijun Wang
In reply to this post by Jamil Nimeh


> On Dec 20, 2017, at 12:02 AM, Jamil Nimeh <[hidden email]> wrote:
>>
>>> - 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?

I don't think so. You can see it is defined inside the Kerberos RFC.

There are 2 key derivations inside Kerberos. You can see them inside the test [1]:

1. From (passphrase,salt,(optional) iteration count) to a basekey, lines 53, 56.

2. From (basekey, usage, type) to an application key, line 165. Here type can be one of checksum, encryption or integrity, and usage can be an arbitrary integer (For example, 1 for issuing a key, 2 for send a message).

It looks the KDF API can be called this way:

KDC kdf = KDF.getInstance("Kerberos5/base");
kdf.init(passphraseAsKey, (salt+count), List.of(empty));
Key baseKey = kdf.deriveKey();

KDC kdf2 = KDF.getInstance("Kerberos5/app");
kdf2.init(baseKey, null, List.of(usage+type));
Key appKey = kdf2.deriveKey();

and either kdf2.init() should be run again and again for different usage+type, or create kdf2 each time.

Or, if there is a deriveKey(DerivationParameterSpec) method, it can be simpler

KDC kdf = KDF.getInstance("Kerberos5");
kdf.init(passphraseAsKey, (salt+count));
Key appKey = kdf2.deriveKey(usage+type);

Thanks
Max

[1] http://cr.openjdk.java.net/~weijun/8014628/webrev.00/test/jdk/sun/security/krb5/etype/KerberosAesSha2.java.html
Reply | Threaded
Open this post in threaded view
|

Re: RFR 8014628: Support AES Encryption with HMAC-SHA2 for Kerberos 5

Jamil Nimeh
Hi Max,

The former approach for KDF would be the correct one.  If this isn't a
derivation algorithm that has use outside our Kerberos implementation
then I'm not sure it's worth making it a general KDF implementation
because of its specificity.  But I have no strong feelings either way.

--Jamil

On 12/19/2017 4:04 PM, Weijun Wang wrote:

>
>> On Dec 20, 2017, at 12:02 AM, Jamil Nimeh <[hidden email]> wrote:
>>>> - 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?
> I don't think so. You can see it is defined inside the Kerberos RFC.
>
> There are 2 key derivations inside Kerberos. You can see them inside the test [1]:
>
> 1. From (passphrase,salt,(optional) iteration count) to a basekey, lines 53, 56.
>
> 2. From (basekey, usage, type) to an application key, line 165. Here type can be one of checksum, encryption or integrity, and usage can be an arbitrary integer (For example, 1 for issuing a key, 2 for send a message).
>
> It looks the KDF API can be called this way:
>
> KDC kdf = KDF.getInstance("Kerberos5/base");
> kdf.init(passphraseAsKey, (salt+count), List.of(empty));
> Key baseKey = kdf.deriveKey();
>
> KDC kdf2 = KDF.getInstance("Kerberos5/app");
> kdf2.init(baseKey, null, List.of(usage+type));
> Key appKey = kdf2.deriveKey();
>
> and either kdf2.init() should be run again and again for different usage+type, or create kdf2 each time.
>
> Or, if there is a deriveKey(DerivationParameterSpec) method, it can be simpler
>
> KDC kdf = KDF.getInstance("Kerberos5");
> kdf.init(passphraseAsKey, (salt+count));
> Key appKey = kdf2.deriveKey(usage+type);
>
> Thanks
> Max
>
> [1] http://cr.openjdk.java.net/~weijun/8014628/webrev.00/test/jdk/sun/security/krb5/etype/KerberosAesSha2.java.html

Reply | Threaded
Open this post in threaded view
|

Re: RFR 8014628: Support AES Encryption with HMAC-SHA2 for Kerberos 5

Weijun Wang


> On Dec 20, 2017, at 8:30 AM, Jamil Nimeh <[hidden email]> wrote:
>
> Hi Max,
>
> The former approach for KDF would be the correct one.  If this isn't a derivation algorithm that has use outside our Kerberos implementation then I'm not sure it's worth making it a general KDF implementation because of its specificity.  But I have no strong feelings either way.

I also don't think it's necessary to provide a algorithm name for this KDF.

This example shows that a deriveKey(deriveParams) is useful.

--Max

>
> --Jamil
>
> On 12/19/2017 4:04 PM, Weijun Wang wrote:
>>
>>> On Dec 20, 2017, at 12:02 AM, Jamil Nimeh <[hidden email]> wrote:
>>>>> - 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?
>> I don't think so. You can see it is defined inside the Kerberos RFC.
>>
>> There are 2 key derivations inside Kerberos. You can see them inside the test [1]:
>>
>> 1. From (passphrase,salt,(optional) iteration count) to a basekey, lines 53, 56.
>>
>> 2. From (basekey, usage, type) to an application key, line 165. Here type can be one of checksum, encryption or integrity, and usage can be an arbitrary integer (For example, 1 for issuing a key, 2 for send a message).
>>
>> It looks the KDF API can be called this way:
>>
>> KDC kdf = KDF.getInstance("Kerberos5/base");
>> kdf.init(passphraseAsKey, (salt+count), List.of(empty));
>> Key baseKey = kdf.deriveKey();
>>
>> KDC kdf2 = KDF.getInstance("Kerberos5/app");
>> kdf2.init(baseKey, null, List.of(usage+type));
>> Key appKey = kdf2.deriveKey();
>>
>> and either kdf2.init() should be run again and again for different usage+type, or create kdf2 each time.
>>
>> Or, if there is a deriveKey(DerivationParameterSpec) method, it can be simpler
>>
>> KDC kdf = KDF.getInstance("Kerberos5");
>> kdf.init(passphraseAsKey, (salt+count));
>> Key appKey = kdf2.deriveKey(usage+type);
>>
>> Thanks
>> Max
>>
>> [1] http://cr.openjdk.java.net/~weijun/8014628/webrev.00/test/jdk/sun/security/krb5/etype/KerberosAesSha2.java.html
>

Reply | Threaded
Open this post in threaded view
|

Re: RFR 8014628: Support AES Encryption with HMAC-SHA2 for Kerberos 5

Weijun Wang
In reply to this post by Sean Mullan


> On Dec 20, 2017, at 5:02 AM, Sean Mullan <[hidden email]> wrote:
>
> On 12/19/17 10:52 AM, Weijun Wang wrote:
>>> * 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.
>
> Ok, I suggest logging the exception if debug is enabled.

The debug flag inside AesDkCrypto and AesSha2DkCrypto are hardcoded to false and not customizable by any system property (and turning it on shows a lot of sensitive things). I can reuse the Krb5.DEBUG flag (controlled by -Dsun.security.krb5.debug=true) but it has never been used inside this level.

Also, the only reason for exception I can see is that a user managed to pack a non-positive iteration count into the s2kparams. This should be quite rare.

If you think this is worth doing, I can modify Krb5.DEBUG to support levels or categories and reuse it inside classes in crypto/dk.

Thanks
Max

>
> --Sean

Reply | Threaded
Open this post in threaded view
|

Re: RFR 8014628: Support AES Encryption with HMAC-SHA2 for Kerberos 5

Weijun Wang
In reply to this post by Weijun Wang


> On Dec 19, 2017, at 11:52 PM, Weijun Wang <[hidden email]> wrote:
>
>> - 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.

CSR: https://bugs.openjdk.java.net/browse/JDK-8193851
Release note: https://bugs.openjdk.java.net/browse/JDK-8193850

Please take a review.

A doc RFE is filed at https://bugs.openjdk.java.net/browse/JDK-8193855.

Thanks
Max
Reply | Threaded
Open this post in threaded view
|

Re: RFR 8014628: Support AES Encryption with HMAC-SHA2 for Kerberos 5

Sean Mullan
In reply to this post by Weijun Wang
On 12/19/17 8:39 PM, Weijun Wang wrote:

>
>
>> On Dec 20, 2017, at 5:02 AM, Sean Mullan <[hidden email]> wrote:
>>
>> On 12/19/17 10:52 AM, Weijun Wang wrote:
>>>> * 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.
>>
>> Ok, I suggest logging the exception if debug is enabled.
>
> The debug flag inside AesDkCrypto and AesSha2DkCrypto are hardcoded to false and not customizable by any system property (and turning it on shows a lot of sensitive things). I can reuse the Krb5.DEBUG flag (controlled by -Dsun.security.krb5.debug=true) but it has never been used inside this level.
>
> Also, the only reason for exception I can see is that a user managed to pack a non-positive iteration count into the s2kparams. This should be quite rare.

Is that a programming error or something that could be from data sent
over the network? If only the former, I would say that those exceptions
should not be suppressed.

The code can also throw GeneralSecurityException but those are also
always suppressed because of the catch block. Is that the right behavior?

--Sean



Reply | Threaded
Open this post in threaded view
|

Re: RFR 8014628: Support AES Encryption with HMAC-SHA2 for Kerberos 5

Weijun Wang


> On Jan 10, 2018, at 12:22 AM, Sean Mullan <[hidden email]> wrote:
>
> On 12/19/17 8:39 PM, Weijun Wang wrote:
>>> On Dec 20, 2017, at 5:02 AM, Sean Mullan <[hidden email]> wrote:
>>>
>>> On 12/19/17 10:52 AM, Weijun Wang wrote:
>>>>> * 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.
>>>
>>> Ok, I suggest logging the exception if debug is enabled.
>> The debug flag inside AesDkCrypto and AesSha2DkCrypto are hardcoded to false and not customizable by any system property (and turning it on shows a lot of sensitive things). I can reuse the Krb5.DEBUG flag (controlled by -Dsun.security.krb5.debug=true) but it has never been used inside this level.
>> Also, the only reason for exception I can see is that a user managed to pack a non-positive iteration count into the s2kparams. This should be quite rare.
>
> Is that a programming error or something that could be from data sent over the network? If only the former, I would say that those exceptions should not be suppressed.

It could be from data sent over the network, this method is called by the client when user uses a username/password pair to login to a KDC. The KDC's response contains the s2kparams value (https://tools.ietf.org/html/rfc4120#section-5.2.7.5) to instruct the user how to generate a key from its password.

>
> The code can also throw GeneralSecurityException but those are also always suppressed because of the catch block. Is that the right behavior?
>

Not a right behavior but should be harmless here. In my understanding, in the case of PBE, as long the passphrase, salt, iteration count etc are legal, there will be no further problem in generating a key, choosing a cipher, and do the encryption work, unless there is a programming error.

I think the original designer (of other etypes) meant to let stringToKey(char,String,byte[]) returning a null when there is an error, and all callers of this method will deal with null instead of an exception. If not programmed carefully, this might turn a GeneralSecurityException to a NullPointerException.

--Max

> --Sean

Reply | Threaded
Open this post in threaded view
|

Re: RFR 8014628: Support AES Encryption with HMAC-SHA2 for Kerberos 5

Sean Mullan
On 1/9/18 8:40 PM, Weijun Wang wrote:
>> The code can also throw GeneralSecurityException but those are also always suppressed because of the catch block. Is that the right behavior?
>>
> Not a right behavior but should be harmless here. In my understanding, in the case of PBE, as long the passphrase, salt, iteration count etc are legal, there will be no further problem in generating a key, choosing a cipher, and do the encryption work, unless there is a programming error.
>
> I think the original designer (of other etypes) meant to let stringToKey(char,String,byte[]) returning a null when there is an error, and all callers of this method will deal with null instead of an exception. If not programmed carefully, this might turn a GeneralSecurityException to a NullPointerException.

Ok, I think this is bad practice, but since it has worked that way since
the beginning, I'm ok with leaving it alone.

--Sean
Reply | Threaded
Open this post in threaded view
|

Re: RFR 8014628: Support AES Encryption with HMAC-SHA2 for Kerberos 5

Weijun Wang
Hi Sean

Do you have other comments on the webrev [1]?

I've also updated the CSR [2].

Thanks
Max

[1] http://cr.openjdk.java.net/~weijun/8014628/webrev.00/
[2] https://bugs.openjdk.java.net/browse/JDK-8193851

> On Jan 13, 2018, at 3:52 AM, Sean Mullan <[hidden email]> wrote:
>
> On 1/9/18 8:40 PM, Weijun Wang wrote:
>>> The code can also throw GeneralSecurityException but those are also always suppressed because of the catch block. Is that the right behavior?
>>>
>> Not a right behavior but should be harmless here. In my understanding, in the case of PBE, as long the passphrase, salt, iteration count etc are legal, there will be no further problem in generating a key, choosing a cipher, and do the encryption work, unless there is a programming error.
>> I think the original designer (of other etypes) meant to let stringToKey(char,String,byte[]) returning a null when there is an error, and all callers of this method will deal with null instead of an exception. If not programmed carefully, this might turn a GeneralSecurityException to a NullPointerException.
>
> Ok, I think this is bad practice, but since it has worked that way since the beginning, I'm ok with leaving it alone.
>
> --Sean

Reply | Threaded
Open this post in threaded view
|

Re: RFR 8014628: Support AES Encryption with HMAC-SHA2 for Kerberos 5

Sean Mullan
On 1/14/18 9:12 PM, Weijun Wang wrote:
> Hi Sean
>
> Do you have other comments on the webrev [1]?

No.

>
> I've also updated the CSR [2].

Ok, thanks.

--Sean

>
> Thanks
> Max
>
> [1] http://cr.openjdk.java.net/~weijun/8014628/webrev.00/
> [2] https://bugs.openjdk.java.net/browse/JDK-8193851
>
>> On Jan 13, 2018, at 3:52 AM, Sean Mullan <[hidden email]> wrote:
>>
>> On 1/9/18 8:40 PM, Weijun Wang wrote:
>>>> The code can also throw GeneralSecurityException but those are also always suppressed because of the catch block. Is that the right behavior?
>>>>
>>> Not a right behavior but should be harmless here. In my understanding, in the case of PBE, as long the passphrase, salt, iteration count etc are legal, there will be no further problem in generating a key, choosing a cipher, and do the encryption work, unless there is a programming error.
>>> I think the original designer (of other etypes) meant to let stringToKey(char,String,byte[]) returning a null when there is an error, and all callers of this method will deal with null instead of an exception. If not programmed carefully, this might turn a GeneralSecurityException to a NullPointerException.
>>
>> Ok, I think this is bad practice, but since it has worked that way since the beginning, I'm ok with leaving it alone.
>>
>> --Sean
>