6 ms·

Libsodium 1.0.0 released

149 points by jedisct1 12y ago

kefka 12y ago
Can someone much smarter than I tell me if this is safe to use? Or better yet, when a time period has passed to consider it safe to use?
- tete 12y ago
  It's probably save to use in the sense that there are a number of projects (dnscrypt, zeromq, tox, ...) are using it already.
  - zrail 12y ago
    When I first started paging through the docs it seemed like sort of a useless, dangerous thing. But now (after reading your comment and looking those projects up) it seems like it's an officially blessed version of NaCL, which makes it seem much safer.
- tptacek 12y ago
  It's better if you don't build crypto directly into your application at all, because you can still screw things up even if you build on Nacl. But with that said: Sodium/Nacl is better than virtually any of your other options for working directly with cryptography.
  - sarciszewski 12y ago
    "It's better if you don't build crypto directly into your application at all" Plaintext all of the things! :P
  - ary 12y ago
    I'm curious to know what you'd recommend for people who are looking to build applications around novel network protocols that aren't interested in the the certificate authority aspect of TLS?
    - bjornsing 12y ago
      There's an RFC on TLS with raw public keys that you should probably check out: http://tools.ietf.org/html/draft-ietf-tls-oob-pubkey-02 http://tools.ietf.org/html/draft-ietf-tls-oob-pubkey-02.
    - tptacek 12y ago
      There's no reason you have to use CAs to authenticate TLS. Plenty of enterprise tools keep whitelists of certificate hashes instead.
    - jewel 12y ago
      There are several TLS modes that don't use certificates. SRP and PSK are the two that I have some limited experience with. Both require sharing a password or key beforehand through some other medium. If you're not concerned with man-in-the-middle attacks, then you could also use the ANON modes.
    - higherpurpose 12y ago
      This maybe: https://github.com/okTurtles/dnschain https://github.com/okTurtles/dnschain
    - revelation 12y ago
      If you control the client software, theres no reason to use a certificate authority instead of making your own CA or just using self-signed certificates.
  - nly 12y ago
    > It's better if you don't build crypto directly into your application at all, because you can still screw things up even if you build on Nacl. Nacl was built to provide an API that is incredibly hard to screw up. That was one of djbs primary motivations. If you just need asymmetric encryption, or signing, or hashing, then it's the bees knees. These broad concepts aren't difficult to comprehend, and every developer should strive to understand and be able to use them. We shouldn't be encouraging people to be afraid... especially when things like dumb, plaintext username and password authentication is routinely implemented by developers without a second thought already.
    - tptacek 12y ago
      Nacl makes it hard to screw up the constructions. It doesn't make it hard to make invalid assumptions about what a signed encrypted blob actually means.
      - illumen 12y ago
        + makes it easy to add two numbers. It doesn't make it hard to make invalid assumptions about what adding two numbers together actually means.
        tptacek 12y ago
        Nacl is a good thing. But crypto is just a tool. It's not a magic wand. People have already built vulnerable systems by making bogus assumptions about what Nacl can do.
        sarciszewski 12y ago
        That's a shame :(
  - sitkack 12y ago
    Can you recommend how to wrap crypto _around_ our applications if we aren't building it in?
- deleted 12y ago
  [deleted]
- duaneb 12y ago
  I believe it's safe to use in the sense of being stable. I don't believe they've had a full security audit yet, though.
  - sarciszewski 12y ago
    Let's not wait 5 years then crowdfund it like TrueCrypt ;)
  - tptacek 12y ago
    People have weird ideas about the protective powers of a "full security audit". This is Bernstein, Lange, and Schwabe's code. There aren't many auditors qualified to review it.
    - sitkack 12y ago
      Theorem provers?
      - nickmeharry 12y ago
        If you want proven crypto, there's always this project: https://github.com/idris-hackers/idris-crypto https://github.com/idris-hackers/idris-crypto
    - duaneb 12y ago
      It's more about having a third party look at it rather than the credentials of the authors being in question.
      - tptacek 12y ago
        I understand the idea, but again: there aren't many third parties that are qualified to evaluate crypto code at all.
- Panino 12y ago
  To add to what others have said here, I'll point you to the authors of TweetNaCl, which sort-of competes with Sodium: http://tweetnacl.cr.yp.to/papers.html http://tweetnacl.cr.yp.to/papers.html Little is said, other than that TweetNaCl is smaller and thus more easily auditable. No criticism. No pointing out failures. Considering the source, that's IMO a serious compliment. (For comparison, read what is said of OpenSSL...) So in short, Sodium is a great library. It was forked from NaCl (the most trustable there is) and has some good features added, like scrypt, BLAKE2 and ChaCha. I think NaCl, TweetNaCl, and Sodium are a great ecosystem, each with different strengths. All great libraries, and the only ones I'd recommend unless you're doing TLS.
  - jedisct1 12y ago
    The ecosystem is actually bigger, and includes projects such as TweetNaCl.js (pure Javascript implementation), Salt (pure PHP implementation) and Chaos.NaCl (pure C# implementation). All these projects play well with each other: they have a decent set of primitives and constructions in common, accessible via a very similar API.
ZoFreX 12y ago
The only part of this I care about right now is the random number generation. It looks good. Pity there's no way to get a float though, for a drop-in drand replacement.
- TillE 12y ago
  Generate 8 random bytes, shove them in an unsigned 64-bit int, then divide that number by 2^64 - 1. I assume that's what any function which returns a random value between 0.0 and 1.0 is actually doing.
  - mjevans 12y ago
    It would probably be faster to directly 'hack' a raw IEEE 754 floating number: http://en.wikipedia.org/wiki/IEEE_754-1985 http://en.wikipedia.org/wiki/IEEE_754-1985 The helpful Examples section already contains the numbers 0 and 1. Let us assume that the output is supposed to be between 0 and 1; it seems that 0 should be inclusive and 1 exclusive for the most balanced 'quick' output. Those two numbers have the leading binary format: 0 (8 or 11 bits exponent) (23 or 52 bits fraction) For either 32 or 64 bit floats. Thus for a float (32 bit): 0 0 (7 bits) (23 bits) 30 bits of randomness are necessary, HOWEVER 0 01111111 is already one when the fraction is all 0s. The easiest solution I can see is to evenly drop some precision: A reference for the casting procedure: http://en.wikipedia.org/wiki/Fast_inverse_square_root#Overview_of_the_code http://en.wikipedia.org/wiki/Fast_inverse_square_root#Overvi... Pseudo: uint32 randomNumber; ... set the random somehow, maybe rand() maybe /dev/urandom etc ... randomNumber &= 0x3F7FFFFF; return * (float *) &randomNumber;
    - ZoFreX 12y ago
      There's a really big problem with dumping random bytes straight into a float, which is that you'll end up with a distribution that, while random, is not linear - i.e. the chance of it being between 0 and 0.5 will not be the same as the chance of it being between 0.5 and 1.0. This is because the gaps between representable numbers increases as the magnitude increases, i.e. there are "more numbers" between 0 and 1 than 100 and 101. The best technique I've found (so far) is to dump the bytes into an int, and divide.
lifeisstillgood 12y ago
I was reading around the zeroMQ implementation of secure messaging that uses this library. It seemed sensible enough (plaintext handshake, exchange session keys and hashes to verify long term keys). But it was entirely couched in "I am not a cryptographer" and "strawman only" caveats. I appreciate the dangers of thinking "encryption cures all other bad decisions" but it would be useful to have a spectrum of security we can talk about. I would love to see something like Big O notation for security - where we are 95% confident that the implementation has closed off vulnerabilities "on the order of published exploits, on the order of passive sniffing inside network, on the order of State level actor targeting your data" I just wonder if we ever can say "hell yes this will do" as opposed to "well even Fort Knox might have a vulnerable point" Edit: perhaps I mean "design patterns for security layers"

149 points by jedisct1 12y ago

kefka 12y ago

Can someone much smarter than I tell me if this is safe to use? Or better yet, when a time period has passed to consider it safe to use?

tete 12y ago
It's probably save to use in the sense that there are a number of projects (dnscrypt, zeromq, tox, ...) are using it already.
- zrail 12y ago
  When I first started paging through the docs it seemed like sort of a useless, dangerous thing. But now (after reading your comment and looking those projects up) it seems like it's an officially blessed version of NaCL, which makes it seem much safer.
tptacek 12y ago
It's better if you don't build crypto directly into your application at all, because you can still screw things up even if you build on Nacl. But with that said: Sodium/Nacl is better than virtually any of your other options for working directly with cryptography.
- sarciszewski 12y ago
  "It's better if you don't build crypto directly into your application at all" Plaintext all of the things! :P
- ary 12y ago
  I'm curious to know what you'd recommend for people who are looking to build applications around novel network protocols that aren't interested in the the certificate authority aspect of TLS?
  - bjornsing 12y ago
    There's an RFC on TLS with raw public keys that you should probably check out: http://tools.ietf.org/html/draft-ietf-tls-oob-pubkey-02 http://tools.ietf.org/html/draft-ietf-tls-oob-pubkey-02.
  - tptacek 12y ago
    There's no reason you have to use CAs to authenticate TLS. Plenty of enterprise tools keep whitelists of certificate hashes instead.
  - jewel 12y ago
    There are several TLS modes that don't use certificates. SRP and PSK are the two that I have some limited experience with. Both require sharing a password or key beforehand through some other medium. If you're not concerned with man-in-the-middle attacks, then you could also use the ANON modes.
  - higherpurpose 12y ago
    This maybe: https://github.com/okTurtles/dnschain https://github.com/okTurtles/dnschain
  - revelation 12y ago
    If you control the client software, theres no reason to use a certificate authority instead of making your own CA or just using self-signed certificates.
- nly 12y ago
  > It's better if you don't build crypto directly into your application at all, because you can still screw things up even if you build on Nacl. Nacl was built to provide an API that is incredibly hard to screw up. That was one of djbs primary motivations. If you just need asymmetric encryption, or signing, or hashing, then it's the bees knees. These broad concepts aren't difficult to comprehend, and every developer should strive to understand and be able to use them. We shouldn't be encouraging people to be afraid... especially when things like dumb, plaintext username and password authentication is routinely implemented by developers without a second thought already.
  - tptacek 12y ago
    Nacl makes it hard to screw up the constructions. It doesn't make it hard to make invalid assumptions about what a signed encrypted blob actually means.
    - illumen 12y ago
      + makes it easy to add two numbers. It doesn't make it hard to make invalid assumptions about what adding two numbers together actually means.
      - tptacek 12y ago
        Nacl is a good thing. But crypto is just a tool. It's not a magic wand. People have already built vulnerable systems by making bogus assumptions about what Nacl can do.
        sarciszewski 12y ago
        That's a shame :(
- sitkack 12y ago
  Can you recommend how to wrap crypto _around_ our applications if we aren't building it in?
deleted 12y ago
[deleted]
duaneb 12y ago
I believe it's safe to use in the sense of being stable. I don't believe they've had a full security audit yet, though.
- sarciszewski 12y ago
  Let's not wait 5 years then crowdfund it like TrueCrypt ;)
- tptacek 12y ago
  People have weird ideas about the protective powers of a "full security audit". This is Bernstein, Lange, and Schwabe's code. There aren't many auditors qualified to review it.
  - sitkack 12y ago
    Theorem provers?
    - nickmeharry 12y ago
      If you want proven crypto, there's always this project: https://github.com/idris-hackers/idris-crypto https://github.com/idris-hackers/idris-crypto
  - duaneb 12y ago
    It's more about having a third party look at it rather than the credentials of the authors being in question.
    - tptacek 12y ago
      I understand the idea, but again: there aren't many third parties that are qualified to evaluate crypto code at all.
Panino 12y ago
To add to what others have said here, I'll point you to the authors of TweetNaCl, which sort-of competes with Sodium: http://tweetnacl.cr.yp.to/papers.html http://tweetnacl.cr.yp.to/papers.html Little is said, other than that TweetNaCl is smaller and thus more easily auditable. No criticism. No pointing out failures. Considering the source, that's IMO a serious compliment. (For comparison, read what is said of OpenSSL...) So in short, Sodium is a great library. It was forked from NaCl (the most trustable there is) and has some good features added, like scrypt, BLAKE2 and ChaCha. I think NaCl, TweetNaCl, and Sodium are a great ecosystem, each with different strengths. All great libraries, and the only ones I'd recommend unless you're doing TLS.
- jedisct1 12y ago
  The ecosystem is actually bigger, and includes projects such as TweetNaCl.js (pure Javascript implementation), Salt (pure PHP implementation) and Chaos.NaCl (pure C# implementation). All these projects play well with each other: they have a decent set of primitives and constructions in common, accessible via a very similar API.

ZoFreX 12y ago

The only part of this I care about right now is the random number generation. It looks good. Pity there's no way to get a float though, for a drop-in drand replacement.

TillE 12y ago
Generate 8 random bytes, shove them in an unsigned 64-bit int, then divide that number by 2^64 - 1. I assume that's what any function which returns a random value between 0.0 and 1.0 is actually doing.
- mjevans 12y ago
  It would probably be faster to directly 'hack' a raw IEEE 754 floating number: http://en.wikipedia.org/wiki/IEEE_754-1985 http://en.wikipedia.org/wiki/IEEE_754-1985 The helpful Examples section already contains the numbers 0 and 1. Let us assume that the output is supposed to be between 0 and 1; it seems that 0 should be inclusive and 1 exclusive for the most balanced 'quick' output. Those two numbers have the leading binary format: 0 (8 or 11 bits exponent) (23 or 52 bits fraction) For either 32 or 64 bit floats. Thus for a float (32 bit): 0 0 (7 bits) (23 bits) 30 bits of randomness are necessary, HOWEVER 0 01111111 is already one when the fraction is all 0s. The easiest solution I can see is to evenly drop some precision: A reference for the casting procedure: http://en.wikipedia.org/wiki/Fast_inverse_square_root#Overview_of_the_code http://en.wikipedia.org/wiki/Fast_inverse_square_root#Overvi... Pseudo: uint32 randomNumber; ... set the random somehow, maybe rand() maybe /dev/urandom etc ... randomNumber &= 0x3F7FFFFF; return * (float *) &randomNumber;
  - ZoFreX 12y ago
    There's a really big problem with dumping random bytes straight into a float, which is that you'll end up with a distribution that, while random, is not linear - i.e. the chance of it being between 0 and 0.5 will not be the same as the chance of it being between 0.5 and 1.0. This is because the gaps between representable numbers increases as the magnitude increases, i.e. there are "more numbers" between 0 and 1 than 100 and 101. The best technique I've found (so far) is to dump the bytes into an int, and divide.

lifeisstillgood 12y ago

I was reading around the zeroMQ implementation of secure messaging that uses this library. It seemed sensible enough (plaintext handshake, exchange session keys and hashes to verify long term keys). But it was entirely couched in "I am not a cryptographer" and "strawman only" caveats. I appreciate the dangers of thinking "encryption cures all other bad decisions" but it would be useful to have a spectrum of security we can talk about. I would love to see something like Big O notation for security - where we are 95% confident that the implementation has closed off vulnerabilities "on the order of published exploits, on the order of passive sniffing inside network, on the order of State level actor targeting your data" I just wonder if we ever can say "hell yes this will do" as opposed to "well even Fort Knox might have a vulnerable point" Edit: perhaps I mean "design patterns for security layers"