6 ms·

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, co

by 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
bogomipz 10y ago
>"but their work is largely restricted to sponges and any construct that can be formed out of it" What does "sponge" mean in the context of crypto implementations? I haven't heard this before which is why I ask.
- niftich 10y ago
  It's a function that takes an input of any length and produces an output of the requested length. From the Keccak (SHA-3) authors [1]: A sponge function is a generalization of both hash functions, which have a fixed output length, and stream ciphers, which have a fixed input length. It operates on a finite state by iteratively applying the inner permutation to it, interleaved with the entry of input or the retrieval of output. (...) On top of its original goal as a security reference, we realized that the sponge construction could also be used to build efficient cryptographic primitives. An important aspect is that the cryptographic primitive to be designed is a fixed-length permutation rather than harder-to-build structures such as block ciphers or dedicated compression functions. This is rather good news in itself, as all the symmetric cryptographic services can be realized using only a single primitive: a fixed-length permutation. As opposed to a block cipher, a fixed-length permutation makes no distinction between data and key input and hence can treat all input bits on an equal footing and at the same time can be made simpler. (...) With its arbitrarily long input and output sizes, the sponge construction allows building various primitives such as a hash function, a stream cipher or a MAC. In some applications the input is short (e.g., a key and a nonce) while the output is long (e.g., a key stream). In other applications, the opposite occurs, where the input is long (e.g., a message to hash) and the output is short (e.g., a digest or a MAC). [1] http://sponge.noekeon.org/ http://sponge.noekeon.org/
  - bogomipz 10y ago
    Thanks for the great explanation and the link. I'm glad I asked. Cheers.
zedred 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. As a casual observer, my impression has been pretty different. Here's an excerpt from the README of curve25519-donna, which it seemed like everyone was using for a while: curve25519 is an elliptic curve, developed by Dan Bernstein, for fast Diffie-Hellman key agreement. DJB's original implementation was written in a language of his own devising called qhasm. The original qhasm source isn't available, only the x86 32-bit assembly output. Since many x86 systems are now 64-bit, and portability is important, this project provides alternative implementations for other platforms. My impression has always been that what we get from DJB is some wacky implementation written in a language of his own devising, or just the 32bit assembler output of that, or some partial code fragment that has to be disentangled from his benchmarking library, and the only thing that makes this usable are people who are motivated to do the work of making it digestible by mortals.
- bsder 10y ago
  > My impression has always been that what we get from DJB is some wacky implementation written in a language of his own devising Go look at TweetNaCl. It's a very small, very clear implementation. In my opinion, the reason why djb was always doing "wacky" stuff was because everybody was always bashing him for being the slowest (it's hard to compete with an AES primitive in hardware). Suddenly, however, performance isn't the boogeyman that it was when nobody else has any useful crypto.
- tptacek 10y ago
  I'm not sure we need to litigate this, because it's not like John Viega and David McGrew contributed the production versions of AES-GCM that everyone uses. More importantly: whatever you think of Bernstein's packaging, an area of expertise he clearly shares with just a small subset of cryptographers is the design of cryptographic primitives optimized for consumer compute hardware. There's a reason his primitives tend to outperform the ones they supplant: until relatively recently, Bernstein was the cryptographer who took this challenge most seriously. Finally: whatever you might think of things like qhasm, it's just a fact that the only mainstream crypto library a majority of crypto engineers are comfortable having generalist developers use is designed (in part) by Bernstein. When you use libsodium, you're (usually) using programming interfaces and constructions he designed.
zrm 10y ago
> 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. It's a little bit more than that. When you look at something like OpenSSL, it gives you two classes of thing. One is very basic primitives (AES, SHA256) that are useless for mortals and begging for misuse, and the other is the monolithic ball of tar that is TLS with X.509 and export ciphers and the whole crooked mess. Bernstein gave us something in the middle. Safe primitives that compose.
- caf 10y ago
  That's not entirely true, OpenSSL also gives you something in the middle - the "Envelope Encryption" functions like EVP_SealInit(). They're just not widely known (and still allow you wide latitude in choosing obsolete primitives).
  - zrm 10y ago
    > the "Envelope Encryption" functions like EVP_SealInit() That thing is a footgun. Those functions encrypt a block of data to a public key without authentication. And encourage you to encrypt to more than one public key at the same time, which is generally a bad idea. The example cipher in the man page is EVP_des_cbc(). It looks like the fact that they're not widely known is the good news. :)
    - loup-vaillant 10y ago
      > Those functions encrypt a block of data to a public key without authentication. How is that a problem? I mean, this is not symmetric crypto where the 2 parties are supposed to share a secret session key. While you generally do want authentication, I can imagine a use case for anonymous messages. Anonymous messages cannot have authentication. Even if they had, the attacker can just block your message and forge another with another public key of his. The receiver won't make a difference, it's a throwaway key to begin with. Did I miss something? In crypto, I often do.
      - 10y ago

by niftich 10y ago

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

bogomipz 10y ago

>"but their work is largely restricted to sponges and any construct that can be formed out of it" What does "sponge" mean in the context of crypto implementations? I haven't heard this before which is why I ask.

niftich 10y ago
It's a function that takes an input of any length and produces an output of the requested length. From the Keccak (SHA-3) authors [1]: A sponge function is a generalization of both hash functions, which have a fixed output length, and stream ciphers, which have a fixed input length. It operates on a finite state by iteratively applying the inner permutation to it, interleaved with the entry of input or the retrieval of output. (...) On top of its original goal as a security reference, we realized that the sponge construction could also be used to build efficient cryptographic primitives. An important aspect is that the cryptographic primitive to be designed is a fixed-length permutation rather than harder-to-build structures such as block ciphers or dedicated compression functions. This is rather good news in itself, as all the symmetric cryptographic services can be realized using only a single primitive: a fixed-length permutation. As opposed to a block cipher, a fixed-length permutation makes no distinction between data and key input and hence can treat all input bits on an equal footing and at the same time can be made simpler. (...) With its arbitrarily long input and output sizes, the sponge construction allows building various primitives such as a hash function, a stream cipher or a MAC. In some applications the input is short (e.g., a key and a nonce) while the output is long (e.g., a key stream). In other applications, the opposite occurs, where the input is long (e.g., a message to hash) and the output is short (e.g., a digest or a MAC). [1] http://sponge.noekeon.org/ http://sponge.noekeon.org/
- bogomipz 10y ago
  Thanks for the great explanation and the link. I'm glad I asked. Cheers.

zedred 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. As a casual observer, my impression has been pretty different. Here's an excerpt from the README of curve25519-donna, which it seemed like everyone was using for a while: curve25519 is an elliptic curve, developed by Dan Bernstein, for fast Diffie-Hellman key agreement. DJB's original implementation was written in a language of his own devising called qhasm. The original qhasm source isn't available, only the x86 32-bit assembly output. Since many x86 systems are now 64-bit, and portability is important, this project provides alternative implementations for other platforms. My impression has always been that what we get from DJB is some wacky implementation written in a language of his own devising, or just the 32bit assembler output of that, or some partial code fragment that has to be disentangled from his benchmarking library, and the only thing that makes this usable are people who are motivated to do the work of making it digestible by mortals.

bsder 10y ago
> My impression has always been that what we get from DJB is some wacky implementation written in a language of his own devising Go look at TweetNaCl. It's a very small, very clear implementation. In my opinion, the reason why djb was always doing "wacky" stuff was because everybody was always bashing him for being the slowest (it's hard to compete with an AES primitive in hardware). Suddenly, however, performance isn't the boogeyman that it was when nobody else has any useful crypto.
tptacek 10y ago
I'm not sure we need to litigate this, because it's not like John Viega and David McGrew contributed the production versions of AES-GCM that everyone uses. More importantly: whatever you think of Bernstein's packaging, an area of expertise he clearly shares with just a small subset of cryptographers is the design of cryptographic primitives optimized for consumer compute hardware. There's a reason his primitives tend to outperform the ones they supplant: until relatively recently, Bernstein was the cryptographer who took this challenge most seriously. Finally: whatever you might think of things like qhasm, it's just a fact that the only mainstream crypto library a majority of crypto engineers are comfortable having generalist developers use is designed (in part) by Bernstein. When you use libsodium, you're (usually) using programming interfaces and constructions he designed.

zrm 10y ago

> 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. It's a little bit more than that. When you look at something like OpenSSL, it gives you two classes of thing. One is very basic primitives (AES, SHA256) that are useless for mortals and begging for misuse, and the other is the monolithic ball of tar that is TLS with X.509 and export ciphers and the whole crooked mess. Bernstein gave us something in the middle. Safe primitives that compose.

caf 10y ago
That's not entirely true, OpenSSL also gives you something in the middle - the "Envelope Encryption" functions like EVP_SealInit(). They're just not widely known (and still allow you wide latitude in choosing obsolete primitives).
- zrm 10y ago
  > the "Envelope Encryption" functions like EVP_SealInit() That thing is a footgun. Those functions encrypt a block of data to a public key without authentication. And encourage you to encrypt to more than one public key at the same time, which is generally a bad idea. The example cipher in the man page is EVP_des_cbc(). It looks like the fact that they're not widely known is the good news. :)
  - loup-vaillant 10y ago
    > Those functions encrypt a block of data to a public key without authentication. How is that a problem? I mean, this is not symmetric crypto where the 2 parties are supposed to share a secret session key. While you generally do want authentication, I can imagine a use case for anonymous messages. Anonymous messages cannot have authentication. Even if they had, the attacker can just block your message and forge another with another public key of his. The receiver won't make a difference, it's a throwaway key to begin with. Did I miss something? In crypto, I often do.
    - 10y ago