Boring Crypto [pdf]
cr.yp.to
cr.yp.to
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.
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.
If you follow that ietf mailing list link, you'll find that TLS1.3 is having some "interesting" arguments right now.
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?
IPSec is a useless nightmare as you say.
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".
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."
Back in '99, there was an IETF working group tasked with creating a chat protocol, with members from all the players at the time (AOL, Microsoft, IBM, Netscape, and a few more). I wasn't part of the wg, but I did follow it closely, and it was clear that some big players only cared about making their own product (as close as possible to) the standard (e.g. Microsoft), and the biggest player (AOL) was just actively sabotaging the process in order to prolong their advantage. Eventually, the group disbanded, and the mostly-working protocol at the time (Jabber -> XMPP) was adopted. It was a horrible ultra verbose under specified mess (and in some cases still is). But it was there, it was working, and it was open.
Good. Then I can focus on building valuable stuff without having to worry about security.
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...
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.
(The online format made this hard to read.)
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.
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.
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.
(the document gets much easier to read when viewed in single page mode)
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 "
(I actually enjoy reading the work he and his colleagues produce.)
http://cr.yp.to/talks/2015.10.05/slides-djb-20151005-4x3.pdf