On 10/22/2015 2:52 AM, Tim Whittington wrote: > draft-agl-tls-chacha20poly1305-04 moved on (incompatibly) to > https://tools.ietf.org/html/draft-mavrogiannopoulos-chacha-tls, which > has since moved on to > https://tools.ietf.org/html/draft-ietf-tls-chacha20-poly1305-00. > Yes. Good that the new proposal follow RFC 5116 specification, and does not use zero fixedIv any more.
Thanks, Xuelei > tim > >> On 13/10/2015, at 3:14 PM, Xuelei Fan <[email protected]> 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 >>> >> >
