7 ms·

I found this particular talk to be different that the usual DJB. It felt more like a self-reflection on why, despite being technically correct, his cryptographi

by jvehent 12y ago

I found this particular talk to be different that the usual DJB. It felt more like a self-reflection on why, despite being technically correct, his cryptographic solutions always fail to gain mainstream traction. I have a lot of respect for DJB and for the way he always challenges the status-quo. This talk is an excellent summary of the current issues in the crypto industry. But he ignores the fact that we use AES, SHA and RC4 because _it's easy to use them_. And his solutions are never easy to use. Make Nacl dead simple to use. Write clients and servers that use it. Integrate it into Firefox, Chrome, Dovecot, Nginx, Postfix, cUrl, etc... and people will slowly move away from TLS and its broken crypto.

chrisballinger 12y ago
Have you seen libsodium [1]? It's a "portable, cross-compilable, installable, packageable fork of NaCl, with a compatible API, and an extended API to improve usability even further." I've been using it in a toy project of mine and so far I'm very impressed! 1. https://github.com/jedisct1/libsodium https://github.com/jedisct1/libsodium
- sillysaurus3 12y ago
  In practice, people are afraid to use libsodium because it was significantly worked on by people other than DJB, and they weren't sure whether it was vetted by DJB. I've personally seen this as an actual reason for avoiding it. And the concern doesn't seem entirely misplaced.
  - Perseids 12y ago
    But why? Would you be afraid to use libreSSL, because the AES implementation wasn't done by Rijmen and Daemon (inventors of AES)? Generally one feature of the Bernstein designs are that they are reasonable simple to implement securely for a competent programmer. By comparison, RSA and the likes are frigging hard to get right because of side channel attacks [1]. [1] http://www.tau.ac.il/~tromer/acoustic/ http://www.tau.ac.il/~tromer/acoustic/
    - tptacek 12y ago
      No, you're missing something. Nacl isn't secure merely because it implements trustworthy algorithms that its authors themselves design. It's secure because it was designed from the ground up to be secure at an implementation level, and (critically) to be misuse-resistant. Equally importantly, the implementation was done by people with a pedigree in building secure misuse-resistant crypto. Sodium (which I like and recommend) can't make the same claim. It gets what trustworthiness it has from the fact that it's a slavish fork of Nacl that merely aims to make it compatible with more runtimes.
      - robryk 12y ago
        Isn't misuse-resistance a property of the interface alone and doesn't it consequently transfer to libsodium? No argument on the other counts.
      - Perseids 12y ago
        > It's secure because it was designed from the ground up to be secure at an implementation level, and (critically) to be misuse-resistant. Ok, interesting. Do you happen to have an example at hand? I don't see where there is room left for much sophistication in the implementation (regarding misuse-resistance), between the well defined algorithms and the strict API that Sodium shares with NaCl. For example lets look at crypto_box (public-key authenticated encryption): On the crypto side it uses Curve25519 (alias X25519). Its paper has a pretty clear definition how to use the public key bytes as an x-coordinate. Because of the Montgomery multiplication an implementation does not have to calculate the y-coordinate, this eliminates one potential error source. Because of (1) its twist security and because (2) any input in a small subgroup results in a zero element output (neutral element or the (0,0) point), an implementation does not have to check the public key for its validity (another error source eliminated). All these are benefits any implementation will have. On the interface side crypto_box is as locked down as a nonce based design can be. You enter: (•) Any 32 byte public key value (X25519 makes sure no harm can be done with malicious values), (•) your 32 bytes private key (not malleable by the attacker), (•) the nonce (during decryption any input is ok, because a wrong input will just generate an authentication error; during encryption there is the danger of nonce reuse, which is also present in NaCl) and (•) the plaintext / crypttext (again, because of the mandatory authentication any malicious ciphertext input will be rejected by the library). So I don't see how a faithful implementation of the interface and algorithm specifications can get much wrong regarding misuse-resistance. Regarding it being secure because it was designed from the ground up to be secure at an implementation level, that is something I expect from any cryptography library. After all, is there any more basic requirement than that? (Well, you could argue being interoperable with other implementations is the most fundamental requirement, but I won't accept such low expectations when I'm asking for a competent developer.) > It gets what trustworthiness it has from the fact that it's a slavish fork of Nacl that merely aims to make it compatible with more runtimes. I fully agree that its inheritance from NaCl is Sodiums strongest selling point and its the argument I should have been using instead. I only had it dimly in the back of my heat at that time, though, and wasn't sure enough about it to claim it as a fact. Being less lazy to look it up would have saved me this follow up post ;) (Though I am genuinely interested in my question above.)
  - wbl 12y ago
    TweetNacl was written by DJB, and implements the same primitives. It's a nearly drop in replacement.
_paulc 12y ago
TweetNaCl (http://tweetnacl.cr.yp.to/software.html http://tweetnacl.cr.yp.to/software.html) is dead easy use - just drop the .c & .h files into your code.
- lisper 12y ago
  Well, it might be dead easy to drop into your code, but that doesn't make it dead easy to use. In fact, it has no documentation (at least not on the page you linked to), so the only way to actually use it is to reverse-engineer it. I'm a big fan of DJB, but the sad fact of the matter is that his stuff is, at the moment, only usable by people who already know what they are doing.
  - wbl 12y ago
    The documentation is on the NaCl site which is linked: they are compatible.
    - lisper 12y ago
      True, but to get to the docs you have to go through three levels of indirection (Introduction -> NaCl -> one of the nine documentation links on the left) and the docs are not exactly beginner friendly. TweetNaCL is a huge advance in usability over full NaCl (which is a freakin' nightmare) but I still say it needs some better documentation if it's going to be usable by anyone who isn't already an expert.
  - _paulc 12y ago
    In most cases you only need a handful of functions - crypto_box_keypair/crypto_box/crypto_box_open for public key crypto and crypto_secretbox/crypto_secretbox_open for private key crypto. It is way simpler than any other crypt library I have used.
    - lisper 12y ago
      Awesome! But that information needs to be on the TNaCL web page, not in an HN comment.
anologwintermut 12y ago
It's a terrible piece of self reflection in that case. His thesis is his stuff never got adopted because of the NSA? DJB is very smart, but he doesn't necessarily play well with others (as tptacek alluded to) and sometimes does some odd things. As a random example: Nacl, which is pretty good, isn't portable. The portable version that someone made, Sodium ripped out a bunch of the platform specific stuff to make it portable, but because no one knows which parts were security critical and which weren't,there more than some doubts. These kind of things matter. Put another way, as a piece of self reflection at least he could figure out how to make it harder for the NSA to marginalize his ideas if that's really the reason they haven't been adopted.
- tptacek 12y ago
  It isn't self-reflection. It's a talk he gave to an audience that puts his research into a current events context and provides a backhanded roadmap to the kinds of crypto research topics that are important to the project of securing the Internet against the NSA. As that, it's pretty effective. It's pretty hard to make a credible argument that Bernstein and Schwabe and Lange did a poor job with Nacl, since the next best alternative is Keyczar, which might not even be maintained anymore. What's the other credible high-level crypto library?
  - anologwintermut 12y ago
    There aren't. Nacl certainly is credible. But it isn't (at least last time I looked) portable. As I understand this is because of a bunch of x86 assembly meant to generate very fast and constant time crypto code. This is Bernstein's entire stick. Which is fine, but if you can't use it on ARM and therefor on mobile, you've killed a large area where adoption of new crypto could actually happen. Arguably, a slower constant time cross platform library would have been a better idea if he actually wanted to see it used widely. This is what Sodium claims to be ....but well who knows if that's secure. And I don't think I agree with you that this is Bernstein merely saying here's why you need what I've done. It's an explanation of why it didn't happen that basically argues that people' are being so stupid about crypto that they might as well be NSA shills. As a narrative it ignores a lot of reasons this stuff didn't happen and a lot of lessons that should be applied in getting it right this time.

by jvehent 12y ago

chrisballinger 12y ago

Have you seen libsodium [1]? It's a "portable, cross-compilable, installable, packageable fork of NaCl, with a compatible API, and an extended API to improve usability even further." I've been using it in a toy project of mine and so far I'm very impressed! 1. https://github.com/jedisct1/libsodium https://github.com/jedisct1/libsodium

sillysaurus3 12y ago
In practice, people are afraid to use libsodium because it was significantly worked on by people other than DJB, and they weren't sure whether it was vetted by DJB. I've personally seen this as an actual reason for avoiding it. And the concern doesn't seem entirely misplaced.
- Perseids 12y ago
  But why? Would you be afraid to use libreSSL, because the AES implementation wasn't done by Rijmen and Daemon (inventors of AES)? Generally one feature of the Bernstein designs are that they are reasonable simple to implement securely for a competent programmer. By comparison, RSA and the likes are frigging hard to get right because of side channel attacks [1]. [1] http://www.tau.ac.il/~tromer/acoustic/ http://www.tau.ac.il/~tromer/acoustic/
  - tptacek 12y ago
    No, you're missing something. Nacl isn't secure merely because it implements trustworthy algorithms that its authors themselves design. It's secure because it was designed from the ground up to be secure at an implementation level, and (critically) to be misuse-resistant. Equally importantly, the implementation was done by people with a pedigree in building secure misuse-resistant crypto. Sodium (which I like and recommend) can't make the same claim. It gets what trustworthiness it has from the fact that it's a slavish fork of Nacl that merely aims to make it compatible with more runtimes.
    - robryk 12y ago
      Isn't misuse-resistance a property of the interface alone and doesn't it consequently transfer to libsodium? No argument on the other counts.
    - Perseids 12y ago
      > It's secure because it was designed from the ground up to be secure at an implementation level, and (critically) to be misuse-resistant. Ok, interesting. Do you happen to have an example at hand? I don't see where there is room left for much sophistication in the implementation (regarding misuse-resistance), between the well defined algorithms and the strict API that Sodium shares with NaCl. For example lets look at crypto_box (public-key authenticated encryption): On the crypto side it uses Curve25519 (alias X25519). Its paper has a pretty clear definition how to use the public key bytes as an x-coordinate. Because of the Montgomery multiplication an implementation does not have to calculate the y-coordinate, this eliminates one potential error source. Because of (1) its twist security and because (2) any input in a small subgroup results in a zero element output (neutral element or the (0,0) point), an implementation does not have to check the public key for its validity (another error source eliminated). All these are benefits any implementation will have. On the interface side crypto_box is as locked down as a nonce based design can be. You enter: (•) Any 32 byte public key value (X25519 makes sure no harm can be done with malicious values), (•) your 32 bytes private key (not malleable by the attacker), (•) the nonce (during decryption any input is ok, because a wrong input will just generate an authentication error; during encryption there is the danger of nonce reuse, which is also present in NaCl) and (•) the plaintext / crypttext (again, because of the mandatory authentication any malicious ciphertext input will be rejected by the library). So I don't see how a faithful implementation of the interface and algorithm specifications can get much wrong regarding misuse-resistance. Regarding it being secure because it was designed from the ground up to be secure at an implementation level, that is something I expect from any cryptography library. After all, is there any more basic requirement than that? (Well, you could argue being interoperable with other implementations is the most fundamental requirement, but I won't accept such low expectations when I'm asking for a competent developer.) > It gets what trustworthiness it has from the fact that it's a slavish fork of Nacl that merely aims to make it compatible with more runtimes. I fully agree that its inheritance from NaCl is Sodiums strongest selling point and its the argument I should have been using instead. I only had it dimly in the back of my heat at that time, though, and wasn't sure enough about it to claim it as a fact. Being less lazy to look it up would have saved me this follow up post ;) (Though I am genuinely interested in my question above.)
- wbl 12y ago
  TweetNacl was written by DJB, and implements the same primitives. It's a nearly drop in replacement.

_paulc 12y ago

TweetNaCl (http://tweetnacl.cr.yp.to/software.html http://tweetnacl.cr.yp.to/software.html) is dead easy use - just drop the .c & .h files into your code.

lisper 12y ago
Well, it might be dead easy to drop into your code, but that doesn't make it dead easy to use. In fact, it has no documentation (at least not on the page you linked to), so the only way to actually use it is to reverse-engineer it. I'm a big fan of DJB, but the sad fact of the matter is that his stuff is, at the moment, only usable by people who already know what they are doing.
- wbl 12y ago
  The documentation is on the NaCl site which is linked: they are compatible.
  - lisper 12y ago
    True, but to get to the docs you have to go through three levels of indirection (Introduction -> NaCl -> one of the nine documentation links on the left) and the docs are not exactly beginner friendly. TweetNaCL is a huge advance in usability over full NaCl (which is a freakin' nightmare) but I still say it needs some better documentation if it's going to be usable by anyone who isn't already an expert.
- _paulc 12y ago
  In most cases you only need a handful of functions - crypto_box_keypair/crypto_box/crypto_box_open for public key crypto and crypto_secretbox/crypto_secretbox_open for private key crypto. It is way simpler than any other crypt library I have used.
  - lisper 12y ago
    Awesome! But that information needs to be on the TNaCL web page, not in an HN comment.

anologwintermut 12y ago

It's a terrible piece of self reflection in that case. His thesis is his stuff never got adopted because of the NSA? DJB is very smart, but he doesn't necessarily play well with others (as tptacek alluded to) and sometimes does some odd things. As a random example: Nacl, which is pretty good, isn't portable. The portable version that someone made, Sodium ripped out a bunch of the platform specific stuff to make it portable, but because no one knows which parts were security critical and which weren't,there more than some doubts. These kind of things matter. Put another way, as a piece of self reflection at least he could figure out how to make it harder for the NSA to marginalize his ideas if that's really the reason they haven't been adopted.

tptacek 12y ago
It isn't self-reflection. It's a talk he gave to an audience that puts his research into a current events context and provides a backhanded roadmap to the kinds of crypto research topics that are important to the project of securing the Internet against the NSA. As that, it's pretty effective. It's pretty hard to make a credible argument that Bernstein and Schwabe and Lange did a poor job with Nacl, since the next best alternative is Keyczar, which might not even be maintained anymore. What's the other credible high-level crypto library?
- anologwintermut 12y ago
  There aren't. Nacl certainly is credible. But it isn't (at least last time I looked) portable. As I understand this is because of a bunch of x86 assembly meant to generate very fast and constant time crypto code. This is Bernstein's entire stick. Which is fine, but if you can't use it on ARM and therefor on mobile, you've killed a large area where adoption of new crypto could actually happen. Arguably, a slower constant time cross platform library would have been a better idea if he actually wanted to see it used widely. This is what Sodium claims to be ....but well who knows if that's secure. And I don't think I agree with you that this is Bernstein merely saying here's why you need what I've done. It's an explanation of why it didn't happen that basically argues that people' are being so stupid about crypto that they might as well be NSA shills. As a narrative it ignores a lot of reasons this stuff didn't happen and a lot of lessons that should be applied in getting it right this time.