Problems with CipherBox and AEAD

[Xuelei Fan]

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 <Xuelei.Fan at Oracle.COM> 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
>>>
>>
>