
Support for ChaCha20-Poly1305 released in OpenSSL 1.1.0 - ktt
https://github.com/openssl/openssl/issues/304
======
wolf550e
"SSL/TLS state machine, version negotiation and record layer rewritten" from
the release notes sounds scary.

The changelog says:

    
    
      *) State machine rewrite. The state machine code has been significantly
         refactored in order to remove much duplication of code and solve issues
         with the old code (see ssl/statem/README for further details). This change
         does have some associated API changes. Notably the SSL_state() function
         has been removed and replaced by SSL_get_state which now returns an
         "OSSL_HANDSHAKE_STATE" instead of an int. SSL_set_state() has been removed
         altogether. The previous handshake states defined in ssl.h and ssl3.h have
         also been removed.
         [Matt Caswell]

~~~
schoen
I would like to see these folks analyze the new code, considering their
success in finding problems in this area before.

[https://www.smacktls.com/](https://www.smacktls.com/)

(I think there is also another group in the UK that works on this problem and
also got important results.)

------
ultramancool
Chacha20 is nice, but I think the key exchange is a bigger problem right now.
What's the situation with Curve25519 in here?

Weak DH and ECDHE using NIST curves concerns me far more than AES-GCM which is
readily available for example. Configuring DH properly requires extra effort
for administrators and ECDHE relies on NIST curves which are prone to
implementation error and some have even called into question the NSA-NIST
relationship behind the "random" curves.

~~~
tptacek
Curve25519 is what's going to happen. The IETF/IRTF process is a clusterfuck
of monumental proportions, and has slowed adoption down, but Chrome and
Firefox will support Curve25519.

The NIST P- curves in TLS ECDHE have sound implementations in Chromium and
Firefox. Nobody should be using conventional DH in preference to ECDHE; if you
can't trust a browser's P-curves, you can't trust their GCM either.

~~~
ultramancool
> if you can't trust a browser's P-curves, you can't trust their GCM either.

Is that true though? I mean, from what I've read GCM seems much easier to
implement than a full ECDH. I mean, have a look at some of the things
published by Bernstein and Lange,
[https://www.hyperelliptic.org/tanja/vortraege/20130531.pdf](https://www.hyperelliptic.org/tanja/vortraege/20130531.pdf)

They do certainly have a horse in the race, but it's still interesting. They
and others have also raised concerns about potential backdoors in the NIST
curves, which is, while still unproven another reason why one might avoid
them. They failed to do things as basic in the cryptographic community as
using "nothing up my sleeve" numbers, it just seems sketchy at best to me. The
random curves at least. The others are probably still just fine but the random
ones are the most popular in TLS.

~~~
tptacek
GCM is extremely tricky to implement safely.

ECDH itself is very easy to implement; it's just DH (which is probably the
simplest algorithm in cryptography), but in a different group.

ECC (the group) is hard to implement safely. The NIST P-curves are tricky to
implement relative to Curve25519.

But there's also a lot more study of how to safely implement the NIST P-
curves than there is for how to make a constant-time GCM.

I don't know. They seem like comparably difficult tasks.

------
tveita
Has this been standardized yet? The latest draft I can find still has a bunch
of 0xTBD values for the cipher suite numbers.

[https://datatracker.ietf.org/doc/draft-ietf-tls-
chacha20-pol...](https://datatracker.ietf.org/doc/draft-ietf-tls-
chacha20-poly1305/03/)

~~~
lorenzhs
Well, the submission literally begins with the words "ChaCha20-Poly1305 is
modern, high performance cipher working in AEAD mode. It was standardized
recently as RFC 7539."
[https://tools.ietf.org/html/rfc7539](https://tools.ietf.org/html/rfc7539)

~~~
tveita
RFC 7539 documents the cipher itself. It's mostly just enshrining the existing
specification as an RFC, except for changing the size of the nonce and block
count to meet recommended nonce sizes.

There are some additional details required to use the cipher for TLS. In
particular the new modes must be assigned entries in the TLS Cipher Suite
Registry, which contain the official names and the numeric values used in the
wire protocol. The current draft also specifies how to construct the nonce
from the record sequence number and a shared secret, to avoid having to send a
nonce with each record.

~~~
lorenzhs
Ah, you meant standardization for use in TLS? I thought you were referring to
the specification of the cipher. Sorry.

------
Zash
Is OpenSSL 1.1.0 really released? The comment linked does not say so, only
that the feature has landed in vcs.

Edit:
[https://openssl.org/news/newslog.html](https://openssl.org/news/newslog.html)
says "Alpha 1 of OpenSSL 1.1.0 is now available"

~~~
protomyth
They probably should have changed "released" to "will be included".

------
dmbaggett
Public shout-out to Andy Polyakov. As a grizzled veteran of assembly coding
from way back in the day, I find his work on openssl hugely impressive.

------
runesoerensen
There are lots of interesting features and changes in this (alpha 1) release.
Release notes and full changelog:
[https://openssl.org/news/openssl-1.1.0-notes.html](https://openssl.org/news/openssl-1.1.0-notes.html)

