"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]
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.
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.
> 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
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.
No cryptographers believe the NIST curves are backdoored. OpenSSL's and NSS's implementations of P-256 have been reviewed and are considered secure. My conclusion is that if your CSPRNG is good, P-256 ECDHE with openssl should be fine.
(specifically the: Jerry Solinas at NSA used this to generate the NIST curves (or so he says))
I believe Matthew Green may have also made a similar statement, though I can't find it, so perhaps I'm not recalling correctly. In any case, I don't think you can outright say "No cryptographers believe the NIST curves are backdoored". You can at best say "No cryptographers have proven the NIST curves are backdoored", which is true.
However, those cryptographers have also raised concerns (including concerns about backdoors) and I just hope we move to safer alternatives quicker.
Schneier's comment is misinformed, and Schneier has had a bias against ECC going back over a decade, which has, I think, kept him from learning as much about it as he's picked up about RSA. Schneier has published no research about ECC, and details of curve crypto are absent from his books.
It's worth keeping in mind that Schneier is also not an academic cryptographer, or really a serious practicing cryptography researcher of any sort. He's a great popularizer and he works with some very credible other researchers, but "Schneier said so" is never going to win a debate among cryptographers.
Bernstein makes the same kinds of comments about the Brainpool curves (the whole point of BADA55 was that the Brainpool curves aren't that much more trustworthy than the Solinas curves), and nobody, including Bernstein, will with a straight face say that the Brainpool curves are backdoored.
It's a valid process critique that has been interpreted by laypeople as an accusation, which is something Bernstein has taken flak for.
Curious that Schneier recommends discrete log crypto in response to a report that the NSA was breaking most crypto. In hindsight, there's a very good chance that the NSA attack in question was the logjam attack against discrete log DH. But, sure, stick with plain DH if it makes you feel safer.
Yes, I think that recommendation was pretty irresponsible, and not just because of Logjam. You are probably safer using NIST P-curve crypto than you are with RSA, and not just because virtually all RSA applications use insecure RSA constructions, but also because RSA includes the huge footgun of having a direct and easy to (unsafely) use Encrypt/Decrypt primitive.
(the ones in the latter brackets) and IANA is very likely to use those. There's always a bit of a chicken and egg race condition here, usually resolved with a friendly mail to the IANA administrator.
While not standardized the amount of people who have been trying to patch openssl to do chacha right now almost makes it a defacto standard. Much of this comes from cloudflare, and I just would warn people about that patch right now. It kind of patches openssl in a weird way.
I say that as someone who is resident on ##openssl and have seen many people try and run into issues.
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
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.
The changelog says: