
Boring Crypto [pdf] - zdw
http://cr.yp.to/talks/2015.10.05/slides-djb-20151005-a4.pdf
======
tptacek
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...](https://www.ietf.org/mail-
archive/web/tls/current/msg17870.html)

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

~~~
sarciszewski
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](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.

~~~
bostik
> _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](https://tools.ietf.org/html/rfc5996)

~~~
tptacek
The IPSEC working group also boasts the hilarious threads where William
Simpson and Perry Metzger ran Phil Rogaway --- Phil Rogaway! --- off the list
for trying, early and without success, to fix some of the more basic crypto
mistakes they were plowing ahead with.

A decade later, Eric Hughes (I think? One of the early cypherpunks) made news
by suggesting that NSA had deliberately sabotaged IPSEC, implanting crypto
vulnerabilities derived (IIRC) from IV handling mistakes. If you go back and
look at the threads, it's pretty clear that wasn't NSA: the personalities
involved aren't hard to track down. It was just garden variety bikeshedding.

The problem definitely _isn 't_ that standards groups attract noisy morons.
William Simpson is very well regarded as a systems person. The problem is that
it puts specialists in one field, specialists from others, and generalists in
a room together, and puts them all on the same tier, and says "let the most
persuasive person win".

~~~
bostik
> _working group also boasts the hilarious threads where William Simpson and
> Perry Metzger ran Phil Rogaway --- Phil Rogaway! --- off the list for
> trying, early and without success, to fix some of the more basic crypto
> mistakes_

I did not know that, thank you for pointing it out.

On the other hand, I think I even read through the other material:

> _A decade later, Eric Hughes (I think? One of the early cypherpunks) made
> news [...]_

I got the link from somewhere, possibly on SILC, and remember the ensuing
discussion. There was a lot of bickering, and one of the comments has remained
with me. Can't remember the exact words, but the context was _" if this was
NSA, they sure knew how to appear juvenile."_

------
thoughtpolice
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](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...](http://csrc.nist.gov/groups/ST/ecc-
workshop-2015/presentations/session6-chou-tung.pdf)

------
vezzy-fnord
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...](https://en.wikipedia.org/wiki/May_you_live_in_interesting_times)

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

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

(The online format made this hard to read.)

~~~
wolf550e
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/Curve25519)

[https://en.wikipedia.org/wiki/Salsa20](https://en.wikipedia.org/wiki/Salsa20)

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

~~~
Spooky23
Don't attribute to malice what is more readily explained by incompetence. Most
infosec people are glorified paper pushers, especially in regulated
environments.

What ends up happening is that "compliance" becomes synonymous with
"security". This manifests itself in numerous ways, like spending millions on
log systems like splint that nobody can access.

------
sarciszewski
Yay, new djb slide deck.

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

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

~~~
tveita
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](http://cr.yp.to/talks/2015.10.05/slides-
djb-20151005-4x3.pdf)

