Hi,
the first point is this suite is maybe only draft, but it is used in
chrome an the strongest suite supported in chrome.
GCM suites are only support in 128bit version,so this was the "request"
to implement it.
The second point is yes this was the only technical problem to get it
running.
Other points where the problem that there are two different RFC vs DRAFT
how to implement it.
But now i got it running. You can see it in action on http://suche.org/
. Since i use the code
from bouncycastle as basis for the CHACHA and POLY i can not publish the
full source here.
But i think it was an good idea to point this out as an problem issue.
Gruß Thomas
Am 14.10.2015 um 00:54 schrieb Bradford Wetmore:
Thomas,
Out of curiosity, are you getting requests for this suite?
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
