RFR: JDK-8140466: ChaCha20-Poly1305 TLS cipher suites

Jamil Nimeh jamil.j.nimeh at oracle.com
Fri Sep 7 00:02:19 UTC 2018


Hi Xuelei, thank you for the comments - my replies are in-line:

On 9/6/2018 2:31 PM, Xuelei Fan wrote:
> SSLCipher.java
> --------------
> line 2159-2164 in the update vs line 1992-1997 in the old file.
>
> The new code is fine, but it takes me a while to analysis the code, 
> and comparing with the old one.  Maybe, we can use the same 
> implementation code for the same logic for maintenance?   Just a very 
> personal preference.  You make the final choice.  If you accept it, 
> please consider other places that compute the nonce value.
Respectfully, I think the way the AES-GCM code sets up the cipher 
doesn't match very well with how ChaCha20 does it.  Even the RFC itself 
says that the nonce construction is different.  There's no per-record 
nonce_explicit and it's really just a padded sequence number XORed with 
the client or server read/write IV.  I think the current code follows 
the procedure in 7905 closely.  Taking the GCM construction will muddy 
it a bit, since things like recordIvSize get brought in...for CC20 
that's always zero, so why have it at all?  It just clutters things IMO.

>
> 2180   sequence);
> 'sn' should be used here.  The 'sequence' variable may be different 
> from the one used for the cipher.
Oh!  Good catch.  I will fix this.
>
> Otherwise, looks fine to me.
>
Thanks Xuelei, much appreciated,
--Jamil

> Thanks,
> Xuelei
>
> On 9/5/2018 9:51 PM, Jamil Nimeh wrote:
>> Hello all,
>> This change will add ChaCha20-Poly1305 cipher suites to our TLS 1.2 
>> and TLS 1.3 implementations.  A few test cases had to be updated to 
>> reflect the new suites as well.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8140466
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8204192
>> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8140466/webrev.01/
>>
>> Thanks,
>> --Jamil




More information about the security-dev mailing list