5 ms·

Support for ChaCha20-Poly1305 released in OpenSSL 1.1.0

91 points by ktt 11y ago

runesoerensen 11y ago
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
tveita 11y ago
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-poly1305/03/ https://datatracker.ietf.org/doc/draft-ietf-tls-chacha20-pol...
- lorenzhs 11y ago
  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 11y ago
    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 11y ago
      Ah, you meant standardization for use in TLS? I thought you were referring to the specification of the cipher. Sorry.
- colmmacc 11y ago
  IANA will officially assign numbers once the I-D has progressed to standard status. They'll show up here: http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4 http://www.iana.org/assignments/tls-parameters/tls-parameter... In the mean time, the I-D does contain the requested values in section 3: TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} {0xCC, 0xA8} TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} {0xCC, 0xA9} TLS_DHE_RSA_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} {0xCC, 0xAA} TLS_PSK_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} {0xCC, 0xAB} TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} {0xCC, 0xAC} TLS_DHE_PSK_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} {0xCC, 0xAD} TLS_RSA_PSK_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} {0xCC, 0xAE} (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.
- xemdetia 11y ago
  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.
Zash 11y ago
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 11y ago
  They probably should have changed "released" to "will be included".
dmbaggett 11y ago
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.
wolf550e 11y ago
"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 11y ago
  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 11y ago
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.
- wolf550e 11y ago
  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. Better ECDHE is ready to be rolled out though: https://tools.ietf.org/html/draft-irtf-cfrg-curves-11 https://tools.ietf.org/html/draft-irtf-cfrg-curves-11 Too bad how long CFRG take to get EdDSA ready.
  - ultramancool 11y ago
    > No cryptographers believe the NIST curves are backdoored. That's not true. For an example, see Schneier's comment here: https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html#c1675929 https://www.schneier.com/blog/archives/2013/09/the_nsa_is_br... Or Bernstein and Lange's comments here: https://www.hyperelliptic.org/tanja/vortraege/20130531.pdf https://www.hyperelliptic.org/tanja/vortraege/20130531.pdf (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.
    - tedunangst 11y ago
      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.

91 points by ktt 11y ago

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

tveita 11y ago

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-poly1305/03/ https://datatracker.ietf.org/doc/draft-ietf-tls-chacha20-pol...

lorenzhs 11y ago
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 11y ago
  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 11y ago
    Ah, you meant standardization for use in TLS? I thought you were referring to the specification of the cipher. Sorry.
colmmacc 11y ago
IANA will officially assign numbers once the I-D has progressed to standard status. They'll show up here: http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4 http://www.iana.org/assignments/tls-parameters/tls-parameter... In the mean time, the I-D does contain the requested values in section 3: TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} {0xCC, 0xA8} TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} {0xCC, 0xA9} TLS_DHE_RSA_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} {0xCC, 0xAA} TLS_PSK_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} {0xCC, 0xAB} TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} {0xCC, 0xAC} TLS_DHE_PSK_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} {0xCC, 0xAD} TLS_RSA_PSK_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} {0xCC, 0xAE} (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.
xemdetia 11y ago
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.

Zash 11y ago

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 11y ago
They probably should have changed "released" to "will be included".

dmbaggett 11y ago

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.

wolf550e 11y ago

"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 11y ago
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 11y ago

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.

wolf550e 11y ago
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. Better ECDHE is ready to be rolled out though: https://tools.ietf.org/html/draft-irtf-cfrg-curves-11 https://tools.ietf.org/html/draft-irtf-cfrg-curves-11 Too bad how long CFRG take to get EdDSA ready.
- ultramancool 11y ago
  > No cryptographers believe the NIST curves are backdoored. That's not true. For an example, see Schneier's comment here: https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html#c1675929 https://www.schneier.com/blog/archives/2013/09/the_nsa_is_br... Or Bernstein and Lange's comments here: https://www.hyperelliptic.org/tanja/vortraege/20130531.pdf https://www.hyperelliptic.org/tanja/vortraege/20130531.pdf (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.
  - tedunangst 11y ago
    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.