6 ms·

NaCl: DJB’s new crypto library

31 points by there 17y ago

cperciva 17y ago
It’s nearly impossible to prevent side channel attacks when your crypto is implemented in a high-level language. AMEN! I've been trying to make this point to people for years, but it has been hard to get anyone to listen -- it's good to have someone else singing from the same songbook.
- jrockway 17y ago
  So how is C immune from this? You don't control the actual codegen anymore, and that can even be at runtime now. (Different codepaths for different invocations of the same function, potentially leaking information via timing.)
  - tptacek 17y ago
    There's a lot of answers for this, but a simple one is that C gives you (much more) control over the memory hierarchy. A carefully written C program can, for instance, keep things most in or out of cache. High-level languages also abstract bignum math, which in number-theoretic crypto is a source of timing channels.
    - NateLawson 17y ago
      Yes, the conventional wisdom is that C is less secure than high-level languages. If you're talking memory management, that's correct. DJB does nothing but stack variables for NaCl to avoid performance and potential for memory leaks. But for side channels, C is almost too high level. For example, it takes assembly code (cpuid) to figure out cache configuration. Even worse, a language like Java or python gives you no control over the memory layout of the key in RAM. So the right combo in my opinion is a carefully tuned C implementation (possibly with a little assembly or compile-time tweaking). Then add your language bindings to call it from a HLL.
      - tptacek 17y ago
        Of course, NaCl isn't written in C; it's written in a combination of C and dynamically-generated assembly (Bernstein wrote his own macro assembler/"high level assembler", qhasm).
pelle 17y ago
This looks like a really killer library. I like the ease of use as well. Now we need Ruby bindings.
SwellJoe 17y ago
It still sounds like Keyczar is the way to go among current available libraries, despite its now multiple discovered exploits (which have presumably been fixed by the time they were disclosed). Regardless of what feature set and implementation is ready for primetime today, I have a question for security folks: Wouldn't it make sense for "the rest of us" (those of us who do not understand crypto beyond a basic comprehension the types and how to use them from a high level) just to pick the most popular crypto library (and backed by a major corporation that has a very strong vested interest in security that works)? Age seems to have merit, as well. We're using OpenSSL, plus Perl bindings, and GPG for our various crypto needs in our products, but if we were doing something fancy, beyond https and encrypting billing data with a public gpg key, what would be the safe choice at this point in time?
- tptacek 17y ago
  The problem with your second graf is that Nate isn't just talking about library implementation bugs. He's saying that the interfaces to some of these libraries are insecure. For instance, you're using OpenSSL; OpenSSL's crypto primitives do essentially nothing to protect you from a host of implementation failures, from failing to properly MAC your messages to leaking error information to checking parameters. Keyczar and OpenSSL are not only not on the same playing field, they aren't playing the same sport. Keyczar is saying, "you want to do crypto, you're not a cryptographer, so we'll make all the hard decisions for you and give you a programmer-proof interface". OpenSSL is saying "here are the control rods, try not to blow the reactor up". As for your first graf, I think it's a bit strange to take a post where a noted, respected expert on crypto is telling you not to use Keyczar, and extract from that the comment that Keyczar seems like the way to go. If Nate says not to use Keyczar, my advice is that picking it right now might be a professional embarassment in the coming year.
  - SwellJoe 17y ago
    As for your first graf, I think it's a bit strange to take a post where a noted, respected expert on crypto is telling you not to use Keyczar, and extract from that the comment that Keyczar seems like the way to go. If Nate says not to use Keyczar, my advice is that picking it right now might be a professional embarassment in the coming year. I read his comments as being "there is nothing good; here's why all of these things suck, but I grudgingly guess Keyczar works for some people". The only alternatives under discussion are cryptlib, which only has C bindings currently, and djb's new thing which uses brand new (well, four year old) ciphers that nobody other than djb really understands or knows to be secure. Given that Keyczar has some major corporate backing, and a reasonable level of community support, it seems a pretty solid choice...despite its imperfections. djb's thing might be an awesome choice...but we don't know and I'm definitely not qualified to figure it out. Again, I'm just some guy, you know? I don't understand the nuances of security very well, but I read what I can and try to make some sense out of the kinds of answers security experts provide (which, for some reason, always seem to be qualified into being no-op statements; I guess because committing to recommending something means you can be proven wrong later when that recommendation proves insecure). So, my reading comprehension I guess is as weak as my crypto knowledge, since I came away thinking, "Well, there's nothing good to use. But maybe Keyczar or cryptlib is better than what we're doing now; djb's might be awesome in the future. cryptlib has an annoying deployment aspect and would require me to write bindings that would probably be insecure, so Keyczar seems maybe the best of a bad lot."
gcv 17y ago
I'm not well-versed in crypto libraries, but is there any reason not to use OpenSSL? That's where I turned when I needed a SHA256 implementation (for a C program), and it worked like a charm. Didn't seem too convoluted to use, either. It has been around long enough that just about every platform has it packaged and ready to use, and dynamically linking against it worked fine everywhere I cared to try.
- gchpaco 17y ago
  OpenSSL has a history of major security bugs. I haven't seen any filed against it recently, and it is widely used, but it gives people the heebie-jeebies, sort of like BIND does. If memory serves it also is a little inflexible if you want to do something a little unconventional. Now, that said, there are certainly sound engineering reasons to continue to use OpenSSL, and in no way should you use any other library that has not seen extensive, extensive security review in its place. NaCl is certainly included there.
  - blasdel 17y ago
    Both OpenSSL and BIND have the unenviable position of being the defaults, and thus get banged on constantly and frequently get integrated poorly. OTOH I think the comparison to BIND is a bit inapt, as OpenSSL was never historically the pile of poorly-architected shit that BIND was.
    - tptacek 17y ago
      If OpenSSL has the kinds of blatant implementation errors that Graham is alluding to (e.g. memcpy memory corruption problems in ASN.1 parses and padding checks), we all have bigger problems than whether he's right about it being a crappy library. A huge number of critically important systems depend on it. I don't love OpenSSL's code --- it's a mess with a zillion different authors and styles --- but the bar for finding horrible problems in it is quite high. The position of being the oft-banged-upon default isn't necessarily unenviable; in OpenSSL's case, it means a lot of crap has been shaken out. The comparison to BIND is superficial; BIND's problems are architectural, OpenSSL's problems stem from it dating back to Eric Young's code, which predates integer overflows and hails from a time when we thought you could mitigate a buffer overflow by malloc'ing instead of allocating on the stack. Don't use OpenSSL --- it's the wrong level abstraction for lay coders --- but yes, don't bash it for the wrong reasons.
deleted 17y ago
[deleted]
kqr2 17y ago
Just in case someone is rusty on their chemistry: NaCl == Sodium Chloride == Salt http://en.wikipedia.org/wiki/Salt_(cryptography) http://en.wikipedia.org/wiki/Salt_(cryptography)
- tptacek 17y ago
  I think it's unlikely that the name is based on password hash salts. That term occurs only very rarely in the cryptographic literature.
  - kqr2 17y ago
    I stand corrected. I believe NaCl stands for Networking and Cryptographic Library. http://secappdev.org/handouts/2009/cryptography%20in%20DNS.pdf http://secappdev.org/handouts/2009/cryptography%20in%20DNS.p...
  - sparky 17y ago
    True, but there is still a namespace conflict within the security world. Google's Native Client (http://code.google.com/p/nativeclient/ http://code.google.com/p/nativeclient/) is called NaCl by the developers, and more and more externally as well :P
    - jrockway 17y ago
      There is also a Common Lisp implementation called NaCL: http://www.cliki.net/NaCL http://www.cliki.net/NaCL

31 points by there 17y ago

It’s nearly impossible to prevent side channel attacks when your crypto is implemented in a high-level language. AMEN! I've been trying to make this point to people for years, but it has been hard to get anyone to listen -- it's good to have someone else singing from the same songbook.

jrockway 17y ago
So how is C immune from this? You don't control the actual codegen anymore, and that can even be at runtime now. (Different codepaths for different invocations of the same function, potentially leaking information via timing.)
- tptacek 17y ago
  There's a lot of answers for this, but a simple one is that C gives you (much more) control over the memory hierarchy. A carefully written C program can, for instance, keep things most in or out of cache. High-level languages also abstract bignum math, which in number-theoretic crypto is a source of timing channels.
  - NateLawson 17y ago
    Yes, the conventional wisdom is that C is less secure than high-level languages. If you're talking memory management, that's correct. DJB does nothing but stack variables for NaCl to avoid performance and potential for memory leaks. But for side channels, C is almost too high level. For example, it takes assembly code (cpuid) to figure out cache configuration. Even worse, a language like Java or python gives you no control over the memory layout of the key in RAM. So the right combo in my opinion is a carefully tuned C implementation (possibly with a little assembly or compile-time tweaking). Then add your language bindings to call it from a HLL.
    - tptacek 17y ago
      Of course, NaCl isn't written in C; it's written in a combination of C and dynamically-generated assembly (Bernstein wrote his own macro assembler/"high level assembler", qhasm).

pelle 17y ago

This looks like a really killer library. I like the ease of use as well. Now we need Ruby bindings.

SwellJoe 17y ago

It still sounds like Keyczar is the way to go among current available libraries, despite its now multiple discovered exploits (which have presumably been fixed by the time they were disclosed). Regardless of what feature set and implementation is ready for primetime today, I have a question for security folks: Wouldn't it make sense for "the rest of us" (those of us who do not understand crypto beyond a basic comprehension the types and how to use them from a high level) just to pick the most popular crypto library (and backed by a major corporation that has a very strong vested interest in security that works)? Age seems to have merit, as well. We're using OpenSSL, plus Perl bindings, and GPG for our various crypto needs in our products, but if we were doing something fancy, beyond https and encrypting billing data with a public gpg key, what would be the safe choice at this point in time?

tptacek 17y ago
The problem with your second graf is that Nate isn't just talking about library implementation bugs. He's saying that the interfaces to some of these libraries are insecure. For instance, you're using OpenSSL; OpenSSL's crypto primitives do essentially nothing to protect you from a host of implementation failures, from failing to properly MAC your messages to leaking error information to checking parameters. Keyczar and OpenSSL are not only not on the same playing field, they aren't playing the same sport. Keyczar is saying, "you want to do crypto, you're not a cryptographer, so we'll make all the hard decisions for you and give you a programmer-proof interface". OpenSSL is saying "here are the control rods, try not to blow the reactor up". As for your first graf, I think it's a bit strange to take a post where a noted, respected expert on crypto is telling you not to use Keyczar, and extract from that the comment that Keyczar seems like the way to go. If Nate says not to use Keyczar, my advice is that picking it right now might be a professional embarassment in the coming year.
- SwellJoe 17y ago
  As for your first graf, I think it's a bit strange to take a post where a noted, respected expert on crypto is telling you not to use Keyczar, and extract from that the comment that Keyczar seems like the way to go. If Nate says not to use Keyczar, my advice is that picking it right now might be a professional embarassment in the coming year. I read his comments as being "there is nothing good; here's why all of these things suck, but I grudgingly guess Keyczar works for some people". The only alternatives under discussion are cryptlib, which only has C bindings currently, and djb's new thing which uses brand new (well, four year old) ciphers that nobody other than djb really understands or knows to be secure. Given that Keyczar has some major corporate backing, and a reasonable level of community support, it seems a pretty solid choice...despite its imperfections. djb's thing might be an awesome choice...but we don't know and I'm definitely not qualified to figure it out. Again, I'm just some guy, you know? I don't understand the nuances of security very well, but I read what I can and try to make some sense out of the kinds of answers security experts provide (which, for some reason, always seem to be qualified into being no-op statements; I guess because committing to recommending something means you can be proven wrong later when that recommendation proves insecure). So, my reading comprehension I guess is as weak as my crypto knowledge, since I came away thinking, "Well, there's nothing good to use. But maybe Keyczar or cryptlib is better than what we're doing now; djb's might be awesome in the future. cryptlib has an annoying deployment aspect and would require me to write bindings that would probably be insecure, so Keyczar seems maybe the best of a bad lot."

gcv 17y ago

I'm not well-versed in crypto libraries, but is there any reason not to use OpenSSL? That's where I turned when I needed a SHA256 implementation (for a C program), and it worked like a charm. Didn't seem too convoluted to use, either. It has been around long enough that just about every platform has it packaged and ready to use, and dynamically linking against it worked fine everywhere I cared to try.

gchpaco 17y ago
OpenSSL has a history of major security bugs. I haven't seen any filed against it recently, and it is widely used, but it gives people the heebie-jeebies, sort of like BIND does. If memory serves it also is a little inflexible if you want to do something a little unconventional. Now, that said, there are certainly sound engineering reasons to continue to use OpenSSL, and in no way should you use any other library that has not seen extensive, extensive security review in its place. NaCl is certainly included there.
- blasdel 17y ago
  Both OpenSSL and BIND have the unenviable position of being the defaults, and thus get banged on constantly and frequently get integrated poorly. OTOH I think the comparison to BIND is a bit inapt, as OpenSSL was never historically the pile of poorly-architected shit that BIND was.
  - tptacek 17y ago
    If OpenSSL has the kinds of blatant implementation errors that Graham is alluding to (e.g. memcpy memory corruption problems in ASN.1 parses and padding checks), we all have bigger problems than whether he's right about it being a crappy library. A huge number of critically important systems depend on it. I don't love OpenSSL's code --- it's a mess with a zillion different authors and styles --- but the bar for finding horrible problems in it is quite high. The position of being the oft-banged-upon default isn't necessarily unenviable; in OpenSSL's case, it means a lot of crap has been shaken out. The comparison to BIND is superficial; BIND's problems are architectural, OpenSSL's problems stem from it dating back to Eric Young's code, which predates integer overflows and hails from a time when we thought you could mitigate a buffer overflow by malloc'ing instead of allocating on the stack. Don't use OpenSSL --- it's the wrong level abstraction for lay coders --- but yes, don't bash it for the wrong reasons.

deleted 17y ago

[deleted]

kqr2 17y ago

Just in case someone is rusty on their chemistry: NaCl == Sodium Chloride == Salt http://en.wikipedia.org/wiki/Salt_(cryptography) http://en.wikipedia.org/wiki/Salt_(cryptography)

tptacek 17y ago
I think it's unlikely that the name is based on password hash salts. That term occurs only very rarely in the cryptographic literature.
- kqr2 17y ago
  I stand corrected. I believe NaCl stands for Networking and Cryptographic Library. http://secappdev.org/handouts/2009/cryptography%20in%20DNS.pdf http://secappdev.org/handouts/2009/cryptography%20in%20DNS.p...
- sparky 17y ago
  True, but there is still a namespace conflict within the security world. Google's Native Client (http://code.google.com/p/nativeclient/ http://code.google.com/p/nativeclient/) is called NaCl by the developers, and more and more externally as well :P
  - jrockway 17y ago
    There is also a Common Lisp implementation called NaCL: http://www.cliki.net/NaCL http://www.cliki.net/NaCL