9 ms·

On the Impending Crypto Monoculture (2016)

246 points by dankohn1 10y ago

cshep 10y ago
I have the fortune of working in a security group who's members are recognised themselves and have worked with Bernstein, Rogaway et al. From my experience, too many cryptographers lack the applied skills (API design, knowing the issues faced by developers, designing and implementing performant crypto primitives). Conversely, too many applied folk lack the crypto experience: knowing the state-of-the-art of elliptic curves, MPC, lattices and so forth. Bernstein has the experience to bridge both, which provides an enormous advantage. JHU's Matthew Green is someone else who's does both.
tempz 10y ago
TLAs will love this. Only one stack to break and/or subvert.
gonzo 10y ago
> "This isn't just theoretical, it actually happened to Colin Percival, a very experienced crypto developer, in his backup program tarsnap." Colin was using AESCTR+HMAC rather than GCM, but there was a nonce reuse bug six years ago: http://www.daemonology.net/blog/2011-01-18-tarsnap-critical-security-bug.html http://www.daemonology.net/blog/2011-01-18-tarsnap-critical-...
Ruud-v-A 10y ago
> Compare this with old-fashioned CBC+HMAC (applied in the correct EtM manner), in which you can arbitrarily misuse the IV (for example you can forget to apply it completely) and the worst that can happen is that you drop back to ECB mode, which isn't perfect but still a long way from the total failure that you get with GCM. It is not. As Dan Boneh stresses in his cryptography course, a cryptosystem is either secure or “terribly, terribly, insecure”.
TazeTSchnitzel 10y ago
(2016)
dvdhnt 10y ago
> In adopting the Bernstein algorithm suite and its implementation, implementers have rejected both the highly brittle and failure-prone current algorithms and mechanisms and their equally brittle and failure-prone implementations. Right for the throat.
lstamour 10y ago
FYI, discussion 10 months ago: https://news.ycombinator.com/item?id=11355742 https://news.ycombinator.com/item?id=11355742
tptacek 10y ago
Reminder, because the term "monoculture" has a powerful negative valence for those of us who remember Slashdot from the 1990s: Guttman isn't arguing that this is a dangerous development, but rather that it's sad that the rest of the cryptographic research community hasn't given Bernstein a run for his money. I suspect the situation will look different 10 years from now: CAESAR will probably spit out a couple strong non-Bernstein AEADs, for instance. And remember, we're still not using a Bernstein hash (though BLAKE traces back to Salsa).
- loup-vaillant 10y ago
  > BLAKE traces back to Salsa Just reviewed some Blake2b, the round structure even integrates the Chacha20 improvements: the quarter-round has the same structure (besides the extra 2 parameters), and their application follows the same SIMD friendly column/diagonal rounds we see in Chacha20.
loup-vaillant 10y ago
I get the point, but the current state of affair encourages me to make it even worse. I'm currently working on a tweetNaCl-like library that will integrate not only Chacha20, but also Blake2b and Argon2i, based on the same ideas. The repeated application of simple ARX based rounds is a damn good idea: it's efficient even for software implementations, it's often "naturally" constant time, and it's simple. Implementing this stuff is easy: if it's Valgrind clean and passes the test vectors, it probably works. It also makes audits and reviews much easier. Similarly, Wegman-Carter authenticators such as Poly1305 are kind of a no-brainer: no forgeries are possible unless you break the cipher itself! Also, fast. Modular arithmetic and potential limb overflow makes them harder to get right but still. Finally, there is simply no escaping elliptic curves. I don't trust the NIST curves. 25519 is not too complex, fast, and doesn't leave enough space in its constants for a backdoor (DJB made sure the design constraints were tight). I mostly agree with this article, but I don't mind a monoculture if it means I get boring crypto.
- amenonsen 10y ago
  Why Blake rather than Keccak? (Maybe I missed some reason why it's a good idea to avoid the latter.)
  - loup-vaillant 10y ago
    I have no good reason to avoid Keccak. As far as I know, it is safe. It did win SHA3 after all. On the other hand, all SHA3 finalists were deemed good enough, and the reasons for Keccak's victory was in part to promote diversity —which I can understand. I couldn't just ignore the other finalists. I've heard that Blake was faster than MD5, and just as safe as Keccak. That decided it. I'm glad I did it, because the code is simple, and turned out to use the same ARX design as Chacha20. Now I can imagine using Keccak instead. But then I'd be tempted to base the entire symmetric cipher-suite on the sponge construction, to share code and cryptanalysis.
- tptacek 10y ago
  None of "simple", "fast", and "not backdoored" capture the real reason why Curve25519 is so deservedly popular; the real issue is that Curve25519 is misuse-resistant: random strings are, for 25519 ECDH, valid public keys, and the arithmetic rules for the curve he chose permit straightforward constant-time implementations. I haven't spoken to a cryptographer who believes the NIST curves are backdoored (or, for that matter, in any of the elaborate hocus-pocus around the Brainpool curves being untrustworthy). But the NIST curves are difficult to use safely, which is why nobody likes them. The NIST backdoor stuff is an argument that appeals more to message board nerds than to practitioners. (Is NIST itself trustworthy? Fuck no. The Dual_EC CSPRNG seems pretty clearly to have been a backdoor at this point.)
khana 10y ago
Why personify crypto? Let the math alone be the driver in this domain. What is solid and true will eventually trickle up.
- treve 10y ago
  Security issues often come from engineering and culture, not math.
- geofft 10y ago
  > Let the math alone be the driver in this domain. What is solid and true will eventually trickle up. Unless you have some way of proving that one-way functions exist, which would imply as a consequence P ≠ NP, this is literally untrue (unless by "eventually" you mean "one day centuries hence, maybe we'll prove P ≠ NP"). There is not a single piece of crypto that can be proven correct today; all crypto that we use is safe because mathematicians have so far been unable to find a practical way to break. This requires mathematicians to be actively trying to break the crypto, so personalities matter because you can't get a worldwide community of experts to study every random person's algorithm. This also requires mathematicians to have a sense of which ways a particular algorithm might be fragile, even if they can't break it quite yet, which requires some non-mathematically-provable trust in the cryptanalyst's good sense. And, of course, if you believe that a certain cryptographer might be inserting back doors or prone to approving crypto that has back doors (see for instance Dual_EC_DRBG), you might distrust other output from that same cryptographer even if you can't prove anything yet.
  - lederhosen 10y ago
    Not only is One-time pad proven secure, it is also obvious without any knowledge of math.
    - geofft 10y ago
      It is not secure: it doesn't provide authentication (integrity protection) and it isn't nonce-reuse-resistant.
makmanalp 10y ago
For those newbies like me wondering about AEADs: https://www.imperialviolet.org/2015/05/16/aeads.html https://www.imperialviolet.org/2015/05/16/aeads.html
- cesarb 10y ago
  Another good one: https://blog.cryptographyengineering.com/2012/05/19/how-to-choose-authenticated-encryption/ https://blog.cryptographyengineering.com/2012/05/19/how-to-c...
michaelt 10y ago
the single biggest, indeed killer failure of the [GCM], the fact that if you for some reason fail to increment the counter, you're sending what's effectively plaintext (it's recoverable with a simple XOR). Is this property particularly unique to GCM? I'd have thought all encryption algorithms would fail if you didn't give them the right inputs?
- taejo 10y ago
  There are many ways an (authenticated) encryption algorithm can fail, including 1. attacker learns the key, and can encrypt and decrypt all messages 2. attacker can encrypt any message 3. attacker can decrypt any message 4. attacker can create a valid random encrypted message, but doesn't know what it says 5. attacker can decrypt only the messages that were wrongly encrypted 6. attacker can determine whether two encrypted messages are the same, but can't decrypt them 7. attacker can determine whether the two wrongly encrypted messages were the same, but can't decrypt them Some of these situations are clearly less bad than others; I'm pretty sure at least #5 can be guaranteed.
- loup-vaillant 10y ago
  Yeah, Chacha20 would fail the same way if we used the same key and nonce for different messages. I'm not sure what he was getting at.
  - s_tec 10y ago
    With Chacha20 the worst that can happen is plaintext recovery, which is a lot less bad than full key recovery.
- tptacek 10y ago
  GCM is uniquely brittle. DJB's Chapoly also falls to nonce misuse (there are NMR schemes, like SIV, but they aren't in wide use), but if you so much as breathe on GCM the wrong way you get key recovery. A good example of this is Furguson's GCM short-tag attack, which is one of Sean Devlin's Set 8 cryptopals exercises. GCM is so bad that when Sean and Hanno gave their GCM talk at Black Hat last year, they were able to inject their slides directly into the TLS session of a GCHQ website and serve them from there.
onlydnaq 10y ago
To be honest, nonce reuse with Bernsteins authenticated encryption algorithms will lead to the same problem as those the author points out with GCM (i.e. plaintext recovery). However, the biggest issue with GCM isn't that the plaintext leaks when reusing nonces, it's the fact that reusing nonces leads to an attacker being able to forge arbitrary ciphertexts.
- loup-vaillant 10y ago
  But… Poly1305 has the same "problem"…
  - tptacek 10y ago
    Guttman's wording here is imprecise. GCM and Poly1305 are not comparably brittle. Both have nonce misuse issues, but GCM has additional problems. See: https://news.ycombinator.com/item?id=13384762 https://news.ycombinator.com/item?id=13384762
theandrewbailey 10y ago
> What's more, the reference implementations of these algorithms also come from Dan Bernstein (again with help from others), leading to a never-before-seen crypto monoculture in which it's possible that the entire algorithm suite used by a security protocol, and the entire implementation of that suite, all originate from one person. We've had crypto monoculture before. 15-20 years ago, we were using RSA, RC4, and MD5. Ron Rivest had a large hand in all of them. They weren't bad for the time, and the bad parts weren't bad because of common authorship.
- JamesLeonis 10y ago
  I think the problem is ultimately the Bus Factor. If we're all relying on one implementation and that implementation is compromised (hit by a bus, a bug, NSA involvement, one bad 0-day, etc), there isn't anything to fall back on. That's my take given the history provided. This may be fixed as time passes and more implementations and crypto experts come together, but it does leave us with a Single Point of Failure nonetheless at this time.
  - loup-vaillant 10y ago
    When a crypto primitive breaks (like MD5 did), we're kinda screwed anyway. On the other hand, bug-free implementations are possible. We have the tools to audit the hell out of them. That kind of pedestrian can be made immune to buses, so to speak.
- tptacek 10y ago
  Let's not forget that the designer of Rijndael (AES) is also the designer of Keccak (SHA-3). RC4, by the way, was bad even for the time. It would be worth studying how it managed to survive as long as it did, because flaws in RC4 were well known long before the browser drama.
  - rockdoe 10y ago
    In the case of SHA-3 it's particularly ironic that the desire to avoid a monoculture in designs led to a monoculture in designers. (The authors of AES had one of the few submissions that was very different from AES and this was a large factor in it getting picked)
niftich 10y ago
As the article says, Bernstein's stuff won out because his work is at the intersection of solid crypto, clean and performant code, and sane API design. This, coupled with the NIST curve debacle that shook public confidence, makes for a compelling case. Part of the problem is there is often a wide gulf between cryptographers and the authors of libraries who then go on to use those algorithms. This is perhaps more acute with approved-by-committee, standardized crypto because library authors may have to implement it to be compatible, despite not being experts in the particular algorithm. In Bernstein's case, he ships (through NaCl) a reference implementation that is good enough to be used in production, and packages complete constructs in ways that are resistant to misuse. This is his innovation -- other libraries tend to offer only the primitives and rely on the user to chain them together in ways that make sense and never in the ways that don't. There are other cryptographers that ship decent reference implementations -- the Keccak team being one -- but their work is largely restricted to sponges and any construct that can be formed out of it (e.g. PRFs, stream ciphers, hash functions). There is perhaps a shortage of people who look at holistic cryptosystems and possess both the domain knowledge and the ideal attitude towards misuse-resistant design.
- niftich 10y ago
  To add to my point, once a few key parties chose Bernstein's crypto, network effects did most of the rest. Adam Langley [1] of Google authored the very first draft [2] of ChaCha20 and Poly1305 in TLS in September 2013 and started the feature request in Mozilla NSS that same month [3], while it presumably shipped in Chromium and BoringSSL earlier. A 2014 Google blog post credits the Poly1305 implementation to Andrew Moon (floodyberry) [4], and the ChaCha20 implementation to Ted Krovetz of CSU Sacramento [5][6]. Meanwhile, a very similar Chacha20+Poly1305 was added [7] to OpenSSH in November 2013 by Damien Miller (djm) [8], who is a longtime OpenSSH contributor but since 2006 has worked for Google. Google likely did this to find a fast cipher that works on hardware that lacks AES acceleration (e.g. phones), but once they did it everyone else followed. This was of course during that awkward time in mid-2013 when no browser supported TLSv1.2 yet, and all TLSv1.1 ciphersuites were insecure [9]. This also coincided with Brian Smith of Mozilla blogging about cutting down on the number of different ciphersuites browsers are to use in the future [10][11], which began a big purge in ciphersuites [12]. [1] https://www.imperialviolet.org/ https://www.imperialviolet.org/ [2] https://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-00 https://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-0... [3] https://bugzilla.mozilla.org/show_bug.cgi?id=917571 https://bugzilla.mozilla.org/show_bug.cgi?id=917571 [4] https://github.com/floodyberry?tab=repositories&q=poly https://github.com/floodyberry?tab=repositories&q=poly [5] http://krovetz.net/csus/ http://krovetz.net/csus/ [6] https://github.com/coruus/chacha/tree/master/ext/supercop/krovetz https://github.com/coruus/chacha/tree/master/ext/supercop/kr... [7] http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/cipher-chachapoly.c http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/cip... [8] http://www.mindrot.org/~djm/ http://www.mindrot.org/~djm/ [9] https://news.ycombinator.com/item?id=12393830 https://news.ycombinator.com/item?id=12393830 [10] https://news.ycombinator.com/item?id=12393683 https://news.ycombinator.com/item?id=12393683 [11] https://briansmith.org/browser-ciphersuites-01 https://briansmith.org/browser-ciphersuites-01 [12] https://bugzilla.mozilla.org/show_bug.cgi?id=1036765 https://bugzilla.mozilla.org/show_bug.cgi?id=1036765
cweimann 10y ago
So djb writes crypto code that works and everybody switches to it but it isn't because his stuff is any good? Through the entire article he doesn't list anything wrong with the djb crypto stuff and ends up calling it 'brakish' and 'camel dung'? Really? It isn't because djb stuff is good, it is because everything else is crap? WTF?
- __jal 10y ago
  Gutmann writes a bit colloquially, and the text was a message on a somewhat informal mailing list. So keep that in mind regarding the tone. The overall point of the post was not to blast DJB, but, well, to point out the crypto monoculture, like it says on the tin. DJB's stuff is good, which is why it is popular. The problem Gutmann is highlighting (mostly) is that nobody's competing with him. That problem? Monocultures are high-risk. A bug or a cryptanalysis breakthrough could render "everybody's" security broken at the same time. Or, DJB is eaten by a bear; who supports that code now?
  - tptacek 10y ago
    If DJB is eaten by a bear I think we'll manage to use Ed25519 and Chapoly just fine Moreover, you can't cryptanalyze Daniel Bernstein himself to break Curve25519 or Chapoly, so he's not a single point of failure. :)
    - deleted 10y ago
      [deleted]

246 points by dankohn1 10y ago

cshep 10y ago

I have the fortune of working in a security group who's members are recognised themselves and have worked with Bernstein, Rogaway et al. From my experience, too many cryptographers lack the applied skills (API design, knowing the issues faced by developers, designing and implementing performant crypto primitives). Conversely, too many applied folk lack the crypto experience: knowing the state-of-the-art of elliptic curves, MPC, lattices and so forth. Bernstein has the experience to bridge both, which provides an enormous advantage. JHU's Matthew Green is someone else who's does both.

tempz 10y ago

TLAs will love this. Only one stack to break and/or subvert.

gonzo 10y ago

> "This isn't just theoretical, it actually happened to Colin Percival, a very experienced crypto developer, in his backup program tarsnap." Colin was using AESCTR+HMAC rather than GCM, but there was a nonce reuse bug six years ago: http://www.daemonology.net/blog/2011-01-18-tarsnap-critical-security-bug.html http://www.daemonology.net/blog/2011-01-18-tarsnap-critical-...

Ruud-v-A 10y ago

> Compare this with old-fashioned CBC+HMAC (applied in the correct EtM manner), in which you can arbitrarily misuse the IV (for example you can forget to apply it completely) and the worst that can happen is that you drop back to ECB mode, which isn't perfect but still a long way from the total failure that you get with GCM. It is not. As Dan Boneh stresses in his cryptography course, a cryptosystem is either secure or “terribly, terribly, insecure”.

TazeTSchnitzel 10y ago

(2016)

dvdhnt 10y ago

> In adopting the Bernstein algorithm suite and its implementation, implementers have rejected both the highly brittle and failure-prone current algorithms and mechanisms and their equally brittle and failure-prone implementations. Right for the throat.

lstamour 10y ago

FYI, discussion 10 months ago: https://news.ycombinator.com/item?id=11355742 https://news.ycombinator.com/item?id=11355742

tptacek 10y ago

Reminder, because the term "monoculture" has a powerful negative valence for those of us who remember Slashdot from the 1990s: Guttman isn't arguing that this is a dangerous development, but rather that it's sad that the rest of the cryptographic research community hasn't given Bernstein a run for his money. I suspect the situation will look different 10 years from now: CAESAR will probably spit out a couple strong non-Bernstein AEADs, for instance. And remember, we're still not using a Bernstein hash (though BLAKE traces back to Salsa).

loup-vaillant 10y ago
> BLAKE traces back to Salsa Just reviewed some Blake2b, the round structure even integrates the Chacha20 improvements: the quarter-round has the same structure (besides the extra 2 parameters), and their application follows the same SIMD friendly column/diagonal rounds we see in Chacha20.

loup-vaillant 10y ago

I get the point, but the current state of affair encourages me to make it even worse. I'm currently working on a tweetNaCl-like library that will integrate not only Chacha20, but also Blake2b and Argon2i, based on the same ideas. The repeated application of simple ARX based rounds is a damn good idea: it's efficient even for software implementations, it's often "naturally" constant time, and it's simple. Implementing this stuff is easy: if it's Valgrind clean and passes the test vectors, it probably works. It also makes audits and reviews much easier. Similarly, Wegman-Carter authenticators such as Poly1305 are kind of a no-brainer: no forgeries are possible unless you break the cipher itself! Also, fast. Modular arithmetic and potential limb overflow makes them harder to get right but still. Finally, there is simply no escaping elliptic curves. I don't trust the NIST curves. 25519 is not too complex, fast, and doesn't leave enough space in its constants for a backdoor (DJB made sure the design constraints were tight). I mostly agree with this article, but I don't mind a monoculture if it means I get boring crypto.

amenonsen 10y ago
Why Blake rather than Keccak? (Maybe I missed some reason why it's a good idea to avoid the latter.)
- loup-vaillant 10y ago
  I have no good reason to avoid Keccak. As far as I know, it is safe. It did win SHA3 after all. On the other hand, all SHA3 finalists were deemed good enough, and the reasons for Keccak's victory was in part to promote diversity —which I can understand. I couldn't just ignore the other finalists. I've heard that Blake was faster than MD5, and just as safe as Keccak. That decided it. I'm glad I did it, because the code is simple, and turned out to use the same ARX design as Chacha20. Now I can imagine using Keccak instead. But then I'd be tempted to base the entire symmetric cipher-suite on the sponge construction, to share code and cryptanalysis.
tptacek 10y ago
None of "simple", "fast", and "not backdoored" capture the real reason why Curve25519 is so deservedly popular; the real issue is that Curve25519 is misuse-resistant: random strings are, for 25519 ECDH, valid public keys, and the arithmetic rules for the curve he chose permit straightforward constant-time implementations. I haven't spoken to a cryptographer who believes the NIST curves are backdoored (or, for that matter, in any of the elaborate hocus-pocus around the Brainpool curves being untrustworthy). But the NIST curves are difficult to use safely, which is why nobody likes them. The NIST backdoor stuff is an argument that appeals more to message board nerds than to practitioners. (Is NIST itself trustworthy? Fuck no. The Dual_EC CSPRNG seems pretty clearly to have been a backdoor at this point.)

khana 10y ago

Why personify crypto? Let the math alone be the driver in this domain. What is solid and true will eventually trickle up.

treve 10y ago
Security issues often come from engineering and culture, not math.
geofft 10y ago
> Let the math alone be the driver in this domain. What is solid and true will eventually trickle up. Unless you have some way of proving that one-way functions exist, which would imply as a consequence P ≠ NP, this is literally untrue (unless by "eventually" you mean "one day centuries hence, maybe we'll prove P ≠ NP"). There is not a single piece of crypto that can be proven correct today; all crypto that we use is safe because mathematicians have so far been unable to find a practical way to break. This requires mathematicians to be actively trying to break the crypto, so personalities matter because you can't get a worldwide community of experts to study every random person's algorithm. This also requires mathematicians to have a sense of which ways a particular algorithm might be fragile, even if they can't break it quite yet, which requires some non-mathematically-provable trust in the cryptanalyst's good sense. And, of course, if you believe that a certain cryptographer might be inserting back doors or prone to approving crypto that has back doors (see for instance Dual_EC_DRBG), you might distrust other output from that same cryptographer even if you can't prove anything yet.
- lederhosen 10y ago
  Not only is One-time pad proven secure, it is also obvious without any knowledge of math.
  - geofft 10y ago
    It is not secure: it doesn't provide authentication (integrity protection) and it isn't nonce-reuse-resistant.

makmanalp 10y ago

For those newbies like me wondering about AEADs: https://www.imperialviolet.org/2015/05/16/aeads.html https://www.imperialviolet.org/2015/05/16/aeads.html

cesarb 10y ago
Another good one: https://blog.cryptographyengineering.com/2012/05/19/how-to-choose-authenticated-encryption/ https://blog.cryptographyengineering.com/2012/05/19/how-to-c...

michaelt 10y ago

the single biggest, indeed killer failure of the [GCM], the fact that if you for some reason fail to increment the counter, you're sending what's effectively plaintext (it's recoverable with a simple XOR). Is this property particularly unique to GCM? I'd have thought all encryption algorithms would fail if you didn't give them the right inputs?

taejo 10y ago
There are many ways an (authenticated) encryption algorithm can fail, including 1. attacker learns the key, and can encrypt and decrypt all messages 2. attacker can encrypt any message 3. attacker can decrypt any message 4. attacker can create a valid random encrypted message, but doesn't know what it says 5. attacker can decrypt only the messages that were wrongly encrypted 6. attacker can determine whether two encrypted messages are the same, but can't decrypt them 7. attacker can determine whether the two wrongly encrypted messages were the same, but can't decrypt them Some of these situations are clearly less bad than others; I'm pretty sure at least #5 can be guaranteed.
loup-vaillant 10y ago
Yeah, Chacha20 would fail the same way if we used the same key and nonce for different messages. I'm not sure what he was getting at.
- s_tec 10y ago
  With Chacha20 the worst that can happen is plaintext recovery, which is a lot less bad than full key recovery.
tptacek 10y ago
GCM is uniquely brittle. DJB's Chapoly also falls to nonce misuse (there are NMR schemes, like SIV, but they aren't in wide use), but if you so much as breathe on GCM the wrong way you get key recovery. A good example of this is Furguson's GCM short-tag attack, which is one of Sean Devlin's Set 8 cryptopals exercises. GCM is so bad that when Sean and Hanno gave their GCM talk at Black Hat last year, they were able to inject their slides directly into the TLS session of a GCHQ website and serve them from there.

onlydnaq 10y ago

To be honest, nonce reuse with Bernsteins authenticated encryption algorithms will lead to the same problem as those the author points out with GCM (i.e. plaintext recovery). However, the biggest issue with GCM isn't that the plaintext leaks when reusing nonces, it's the fact that reusing nonces leads to an attacker being able to forge arbitrary ciphertexts.

loup-vaillant 10y ago
But… Poly1305 has the same "problem"…
- tptacek 10y ago
  Guttman's wording here is imprecise. GCM and Poly1305 are not comparably brittle. Both have nonce misuse issues, but GCM has additional problems. See: https://news.ycombinator.com/item?id=13384762 https://news.ycombinator.com/item?id=13384762

theandrewbailey 10y ago

> What's more, the reference implementations of these algorithms also come from Dan Bernstein (again with help from others), leading to a never-before-seen crypto monoculture in which it's possible that the entire algorithm suite used by a security protocol, and the entire implementation of that suite, all originate from one person. We've had crypto monoculture before. 15-20 years ago, we were using RSA, RC4, and MD5. Ron Rivest had a large hand in all of them. They weren't bad for the time, and the bad parts weren't bad because of common authorship.

JamesLeonis 10y ago
I think the problem is ultimately the Bus Factor. If we're all relying on one implementation and that implementation is compromised (hit by a bus, a bug, NSA involvement, one bad 0-day, etc), there isn't anything to fall back on. That's my take given the history provided. This may be fixed as time passes and more implementations and crypto experts come together, but it does leave us with a Single Point of Failure nonetheless at this time.
- loup-vaillant 10y ago
  When a crypto primitive breaks (like MD5 did), we're kinda screwed anyway. On the other hand, bug-free implementations are possible. We have the tools to audit the hell out of them. That kind of pedestrian can be made immune to buses, so to speak.
tptacek 10y ago
Let's not forget that the designer of Rijndael (AES) is also the designer of Keccak (SHA-3). RC4, by the way, was bad even for the time. It would be worth studying how it managed to survive as long as it did, because flaws in RC4 were well known long before the browser drama.
- rockdoe 10y ago
  In the case of SHA-3 it's particularly ironic that the desire to avoid a monoculture in designs led to a monoculture in designers. (The authors of AES had one of the few submissions that was very different from AES and this was a large factor in it getting picked)

niftich 10y ago

As the article says, Bernstein's stuff won out because his work is at the intersection of solid crypto, clean and performant code, and sane API design. This, coupled with the NIST curve debacle that shook public confidence, makes for a compelling case. Part of the problem is there is often a wide gulf between cryptographers and the authors of libraries who then go on to use those algorithms. This is perhaps more acute with approved-by-committee, standardized crypto because library authors may have to implement it to be compatible, despite not being experts in the particular algorithm. In Bernstein's case, he ships (through NaCl) a reference implementation that is good enough to be used in production, and packages complete constructs in ways that are resistant to misuse. This is his innovation -- other libraries tend to offer only the primitives and rely on the user to chain them together in ways that make sense and never in the ways that don't. There are other cryptographers that ship decent reference implementations -- the Keccak team being one -- but their work is largely restricted to sponges and any construct that can be formed out of it (e.g. PRFs, stream ciphers, hash functions). There is perhaps a shortage of people who look at holistic cryptosystems and possess both the domain knowledge and the ideal attitude towards misuse-resistant design.

niftich 10y ago
To add to my point, once a few key parties chose Bernstein's crypto, network effects did most of the rest. Adam Langley [1] of Google authored the very first draft [2] of ChaCha20 and Poly1305 in TLS in September 2013 and started the feature request in Mozilla NSS that same month [3], while it presumably shipped in Chromium and BoringSSL earlier. A 2014 Google blog post credits the Poly1305 implementation to Andrew Moon (floodyberry) [4], and the ChaCha20 implementation to Ted Krovetz of CSU Sacramento [5][6]. Meanwhile, a very similar Chacha20+Poly1305 was added [7] to OpenSSH in November 2013 by Damien Miller (djm) [8], who is a longtime OpenSSH contributor but since 2006 has worked for Google. Google likely did this to find a fast cipher that works on hardware that lacks AES acceleration (e.g. phones), but once they did it everyone else followed. This was of course during that awkward time in mid-2013 when no browser supported TLSv1.2 yet, and all TLSv1.1 ciphersuites were insecure [9]. This also coincided with Brian Smith of Mozilla blogging about cutting down on the number of different ciphersuites browsers are to use in the future [10][11], which began a big purge in ciphersuites [12]. [1] https://www.imperialviolet.org/ https://www.imperialviolet.org/ [2] https://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-00 https://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-0... [3] https://bugzilla.mozilla.org/show_bug.cgi?id=917571 https://bugzilla.mozilla.org/show_bug.cgi?id=917571 [4] https://github.com/floodyberry?tab=repositories&q=poly https://github.com/floodyberry?tab=repositories&q=poly [5] http://krovetz.net/csus/ http://krovetz.net/csus/ [6] https://github.com/coruus/chacha/tree/master/ext/supercop/krovetz https://github.com/coruus/chacha/tree/master/ext/supercop/kr... [7] http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/cipher-chachapoly.c http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/cip... [8] http://www.mindrot.org/~djm/ http://www.mindrot.org/~djm/ [9] https://news.ycombinator.com/item?id=12393830 https://news.ycombinator.com/item?id=12393830 [10] https://news.ycombinator.com/item?id=12393683 https://news.ycombinator.com/item?id=12393683 [11] https://briansmith.org/browser-ciphersuites-01 https://briansmith.org/browser-ciphersuites-01 [12] https://bugzilla.mozilla.org/show_bug.cgi?id=1036765 https://bugzilla.mozilla.org/show_bug.cgi?id=1036765

cweimann 10y ago

So djb writes crypto code that works and everybody switches to it but it isn't because his stuff is any good? Through the entire article he doesn't list anything wrong with the djb crypto stuff and ends up calling it 'brakish' and 'camel dung'? Really? It isn't because djb stuff is good, it is because everything else is crap? WTF?

__jal 10y ago
Gutmann writes a bit colloquially, and the text was a message on a somewhat informal mailing list. So keep that in mind regarding the tone. The overall point of the post was not to blast DJB, but, well, to point out the crypto monoculture, like it says on the tin. DJB's stuff is good, which is why it is popular. The problem Gutmann is highlighting (mostly) is that nobody's competing with him. That problem? Monocultures are high-risk. A bug or a cryptanalysis breakthrough could render "everybody's" security broken at the same time. Or, DJB is eaten by a bear; who supports that code now?
- tptacek 10y ago
  If DJB is eaten by a bear I think we'll manage to use Ed25519 and Chapoly just fine Moreover, you can't cryptanalyze Daniel Bernstein himself to break Curve25519 or Chapoly, so he's not a single point of failure. :)
  - deleted 10y ago
    [deleted]