Boring Crypto [pdf]

http://cr.yp.to/talks/2015.10.05/slides-djb-20151005-a4.pdf

by zdw • 11 years ago

91 24 11 years ago

cr.yp.to

teach• 11 years ago

So he's advocating a particular block cipher (X25519)?

(The online format made this hard to read.)

wolf550e• 11 years ago

Curve25519 does elliptic curve Diffie Hellman key exchange, not a cipher. The related Ed25519 does elliptic curve digital signatures. Both are used in modern crypto protocols like nacl and libsodium and both are being standardized for TLS. Newer versions of openssh use them with ssh.

His cipher which is recommended together with those is chacha20. It is used with poly1305 MAC. It is a stream cipher, not a block cipher, and it is used with AEAD API. They too are already used in ssh and are being standardized for TLS. Chrome already uses them for TLS when talking to Google services if the client does not have hardware AES.

https://en.wikipedia.org/wiki/Curve25519

https://en.wikipedia.org/wiki/Salsa20

api• 11 years ago

We decided to use this cipher suite in our own product for some of the same reasons he mentions. Yet a lot of the general developer community is always like "Wut!?!?!? you didn't use AES!?!?"

We've considered swapping it out or adding alternatives multiple times, especially when we were told that not being NIST/FIPS can lock you out of some enterprise markets. "Nobody ever got fired for using FIPS compliant crypto." But each time we've decided that the added complexity (and therefore attack surface, bugs, overhead, etc.) isn't worth it, especially since we have yet to find an actual concrete customer who turned us down because we're not FIPS.

I'm very happy to see Google and OpenSSH implementing this stuff. It will really help with credibility among the non-crypto-savvy. "No, it's not FIPS, but Google and Apple use it."

Side node: I worked once as a consultant with a government lab. Had to use FIPS. When vulnerabilities would come around, we'd have to scramble to harden our firewall because we couldn't upgrade to fixed versions because there was no FIPS-compliant fix yet. In some cases we had to run vulnerable. We also had to lag way behind on using smart card auth because the full stack wasn't FIPS yet on all Linux distributions. We were hacked once and none of the smart card auth'd systems got compromised, but much of the network did because it wasn't hardware access controlled yet... because of FIPS. If the conspiracy theories are right and FIPS (and NIST) are out to weaken crypto, it's working... but mostly for government and government-linked customers. Anyone who ignores FIPS and cargo-cult "best practices" is likely to be more secure.

Kristine1975• 11 years ago

I think he advocates for crypto implementations that are provably secure. Provably secure = boring, because there are no security holes to be found.

(the document gets much easier to read when viewed in single page mode)

tveita2• 11 years ago

Maybe he's arguing for implementations that are provably correct, but I don't think DJB is a big fan of "provable security".

https://twitter.com/hashbreaker/status/294465109613477889, "Some evidence that "provable security" is negatively correlated with actual security: http://cr.yp.to/talks/2013.01.23/slides.pdf "

wanderfowl• 11 years ago

Agreed. Beamer's excellent, but for a static PDF which is not your intended presentation copy, it's cruel and unusual to expect people to read a copy with all the build steps.

sarciszewski3• 11 years ago

Yay, new djb slide deck.

(I actually enjoy reading the work he and his colleagues produce.)

thoughtpolice• 11 years ago

Overall, pretty layman slide deck (for DJB anyway) and some good notes. Was just talking about RC4/BEAST with someone yesterday.

Related slides from Peter Schwabe, documenting the `gfverify` component djb mentioned near the end, to verify Curve25519: http://ecc2015.math.u-bordeaux1.fr/documents/schwabe.pdf

Another interesting paper just from there for performance minded people, "Sandy2x: The Fastest Curve25519 Implementation Ever" - http://csrc.nist.gov/groups/ST/ecc-workshop-2015/presentatio...

vezzy-fnord• 11 years ago

On a tangential note, the phrase "May you live in interesting times" actually has no precise Chinese equivalent or origin despite it being famous as such: https://en.wikipedia.org/wiki/May_you_live_in_interesting_ti...

tptacek2• 11 years ago

Perfect example of exactly the phenomenon he's talking about, just from today! Read the whole thread to see the boring vs. exciting debate fleshed out.

https://www.ietf.org/mail-archive/web/tls/current/msg17870.h...

(h/t Filippo Valsorda).

Also: if I can take a stab at reframing this: I don't think this is properly seen as a discussion between "boring" and "exciting". Curve25519, Poly1305, and Salsa20 aren't boring! Salsa20 is the first popular native stream cipher since RC4.

What this is really about is standards crypto vs soundly engineered crypto.

Virtually all of Bernstein's problems, going all the way back through his career, stem from the way standards bodies mangle cryptography.

sarciszewski3• 11 years ago

If we're using the word "boring" as a euphemism for "well engineered, less likely to cause a fire", Salsa20 is slightly less boring than ChaCha20, but far more boring than RC4. https://github.com/CodesInChaos/SalsaBias :)

I hope we see TLS 1.3 some time soon.

Virtually all of Bernstein's problems, going all the way back through his career, stem from the way standards bodies mangle cryptography.

The more I read about his career, the clearer this becomes. It almost makes me wish we could abolish standards committees.

chetanahuja2• 11 years ago

I hope we see TLS 1.3 some time soon

If you follow that ietf mailing list link, you'll find that TLS1.3 is having some "interesting" arguments right now.

bostik2• 11 years ago

It almost makes me wish we could abolish standards committees.

I have for some time let myself believe that standards committees are a politically correct way to ensure incompatibility.

My boss/supervisor from an earlier life was a regular in IETF IPSec working group. (This would have been in 2004-2005.) He commented, on several occasions, that the reason IPSec was such a travesty of a spec was because the working group was infested(!) by employees from all the big players. Each of whom made absolutely sure that their bastardised version of IPSec was allowed (and therefore declared compatible) by the spec, no matter now insane, inane or outright nonsensical it was. I still remember with horror the kinds of contortions we had to make our code do to support L2TP IPSec with native clients on multiple OS's. (Think: kernel patches that would cause maintainers to claw their eyes out.)

He also quipped that IKEv2 was supposed to fix most of the problems encountered with IKEv1, but thanks to the special interests involved, he didn't expect it to come out any time soon, and even then he had no idea how badly it would be watered down when it did. The RFC for IKEv2 eventually came out in 2010.[0] I haven't had much of a look, to be honest.

Apart from Cisco and Juniper, is anyone even really using IPSec for real these days?

0: https://tools.ietf.org/html/rfc5996

wglb2• 11 years ago

With respect to wish we could abolish standards committees, he is also out to abolish the security industry. An idea not without its underpinning merits.

qznc• 11 years ago

Why portrait format? It is obviously meant for a presentation, since there are overlays. Does djb turn his beamer over?

tveita2• 11 years ago

To show both the current and the previous slide, I believe. Here's the horizontal format, complete with fancy scrolling animations:

http://cr.yp.to/talks/2015.10.05/slides-djb-20151005-4x3.pdf

chetanahuja2• 11 years ago

The entire premise of TLS suffers from the massiveness of the problem it's trying to solve.

There are billions of users running 100's of varieties of web browsers with varying levels of support and backward compatibility requirements trying to connect to millions of "secure" websites using a third party trust scheme involving 100's of certificate authorities across a profoundly untrusted network.

The litany of attacks listed in djb's preso covers only the pure crypto based vulnerabilities. He doesn't even go into the fundamentally broken model of HTTP->HTTPS transition, the problem of any cert authority's ability to create absolutely any certificate without any central control, the social problem of browser users not really understanding the complex error messages and vagaries of the browser UI's indicating various levels of trust, the complexities of cert and key management for small and mid sized site operators and so on and so forth.

Browser vendors' reaction to every problem seems to be to add yet another flag or HTTP header in the protocol negotiation phase and yet another acronym for site operators and users to get used to. I for one am not optimistic that we'll ever get to the level of "boring security" (not just boring crypto) that djb would like.

Boring Crypto [pdf]

Related Stories