A couple comments:
> Were ChaCha20 and Poly1305 based cipher suites accepted as IETF RFC?
> Looks like the proposal was not moving forward since May, 2014.
>
> https://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-04
AFAIK, CHACHA20/Poly1305 based suites were never issued ciphersuite numbers.
http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml
The following suites are in the "Unassigned" section, so I assume they
are just for this draft:
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 = {0xcc, 0x13}
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 = {0xcc, 0x14}
TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 = {0xcc, 0x15}
As you probably know, we haven't supported anything like that (Stream
cipher + Poly1305 as an AEAD). I wouldn't be surprised if there were
other problems.
Brad
On 10/12/2015 7:14 PM, Xuelei Fan wrote:
Were ChaCha20 and Poly1305 based cipher suites accepted as IETF RFC?
Looks like the proposal was not moving forward since May, 2014.
https://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-04
Thanks,
Xuelei
On 10/11/2015 3:59 PM, Thomas Lußnig wrote:
Hi,
when i extends "sun.security.ssl.CipherSuite" with
final static BulkCipher B_CHACHA20_POLY1305 = new
BulkCipher("CHACHA20_POLY1305", AEAD_CIPHER , 32 ,32, 0, 0, true );
i found an Problem in "sun.security.ssl.CipherBox
Method "applyExplicitNonce" there for the AEAD_CIPHER case is an NPE if
the IV Length is zero. Then fixedIv become null
and there is an NPE. The Workaround for this is
final byte[] iv;
if(this.fixedIv == null) { // FIX for CHACHA
iv = new byte[this.recordIvSize]; // CHACHA fix
bb.get(iv, 0, this.recordIvSize);
} else {
iv = Arrays.copyOf(this.fixedIv, this.fixedIv.length +
this.recordIvSize);
bb.get(iv, this.fixedIv.length, this.recordIvSize);
}
Another problem would occour if i use "new
BulkCipher("CHACHA20_POLY1305", AEAD_CIPHER , 32 ,32, 8, 8, true );"
Then in createExplicitNonce the nonce should become zero size but is
fixed length for AEAD of 8 bytes.
Both was seen in JDK-1.8.0_60
Gruß Thomas Lußnig
