Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Support for ChaCha20-Poly1305 released in OpenSSL 1.1.0

github.com

Post reply on HN
Print view View original

11–20 of 24 posts

Re: Support for ChaCha20-Poly1305 released in OpenSSL 1.1.0

#11

Post by lorenzhs »

tveita wrote: post #6
lorenzhs wrote: post #3

Earlier quoted context omitted.

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…

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

Re: Support for ChaCha20-Poly1305 released in OpenSSL 1.1.0

#12

Post by schoen »

wolf550e wrote: post #10

"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…

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/

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

Re: Support for ChaCha20-Poly1305 released in OpenSSL 1.1.0

#13

Post by xemdetia »

tveita wrote: post #2

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...

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.

Re: Support for ChaCha20-Poly1305 released in OpenSSL 1.1.0

#14

Post by 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.

Re: Support for ChaCha20-Poly1305 released in OpenSSL 1.1.0

#15

Post by wolf550e »

ultramancool wrote: post #14

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-N…

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

Too bad how long CFRG take to get EdDSA ready.

Re: Support for ChaCha20-Poly1305 released in OpenSSL 1.1.0

#16

Post by tptacek »

ultramancool wrote: post #14

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-N…

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.

Re: Support for ChaCha20-Poly1305 released in OpenSSL 1.1.0

#17

Post by ultramancool »

wolf550e wrote: post #15
ultramancool wrote: post #14

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-N…

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 Too bad how long CFRG take to get EdDSA ready.

> 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_br...

Or Bernstein and Lange's comments here:

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.

Re: Support for ChaCha20-Poly1305 released in OpenSSL 1.1.0

#18

Post by ultramancool »

tptacek wrote: post #16
ultramancool wrote: post #14

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-N…

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.

Re: Support for ChaCha20-Poly1305 released in OpenSSL 1.1.0

#19

Post by tedunangst »

ultramancool wrote: post #17
wolf550e wrote: post #15

Earlier quoted context omitted.

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 Too bad how long CFRG take to get EdDSA ready.

> 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_br... Or Bernstein and Lange's comments here: 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 ma…

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.

Re: Support for ChaCha20-Poly1305 released in OpenSSL 1.1.0

#20

Post by tptacek »

ultramancool wrote: post #18
tptacek wrote: post #16

Earlier quoted context omitted.

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 c…

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.

Post reply on HN