3 ms·

Saved you a click: it's many of the same ideas as libsodium, but mostly with ChaCha and allegedly easier to deploy. I'm not sure I believe the latter, and my re

by lvh 10y ago

Saved you a click: it's many of the same ideas as libsodium, but mostly with ChaCha and allegedly easier to deploy. I'm not sure I believe the latter, and my recommendation to use libsodium stands. ChaCha20 is also available (but only in AEAD mode with Poly1305) in libsodium, if you really need it. I think XSalsa20 is a reasonable default: if you had a protocol where there's an obvious sequence number to use as a nonce, you probably should already be using TLS anyway; most of the things where libsodium is your best option is precisely in the cases where you don't have the luxury of solving that sort of coordination problem, and you want a random nonce (and hence, extended-nonce versions like XSalsa20 or XChaCha20. I don't know of anyone who has deployed XChaCha20, although the construction is "obvious".) I've previously criticized a blog by the same author called Rolling Your Own Crypto, which had serious flaws. AFAICT, this is ostensibly cryptographically fine (modulo some safeguards that probably only matter if you're Doing It Wrong already anyway), even though the final recommendation is still "avoid". There are many things I disagree with (don't put the documentation for the internal hash for ChaCha20 before the authenticated encryption API!), and using TweetNaCl as a base is less interesting than using libsodium which is both fast and has a lot more eyeballs on it.

loup-vaillant 10y ago
> allegedly easier to deploy. One .c file, one .h file. No fancy compiler option. It doesn't get any easier. I agree with most of the rest, including the "avoid" recommendation, since Monocypher had only one pair of eyeballs so far. > There are many things I disagree with Please, I need more! (The documentation order was out of laziness, I'll change it.) > using TweetNaCl as a base is less interesting than using libsodium which is both fast and has a lot more eyeballs on it. TweetNaCl is smaller. Much smaller. It doesn't need nearly as many eyeballs as libsodium to reach the same level of confidence. And I'm not sure libsodium had as much audits and static analyses as TweetNaCl, if only because its size may render some analyses impractical. I tried to use ref10 as a base. It's too much code.
- lvh 10y ago
  I'd disagree with "easier to deploy". Most users are going to do this via FFI, and then one .c and one .h pales in comparison to "already has a dylib/so" I can use. It may be true that it doesn't need as many eyeballs; alternative implementations of the same code have the benefit that they're pretty easy to automatedly check. libsodium is not anywhere near the size where static analyses become impractical -- do you have any evidence that would support that?
  - loup-vaillant 10y ago
    > Most users are going to do this via FFI The C interface is the first step. I may consider C++ and OCaml bindings in the future. Still, point taken: calling C from other languages is always a bit of a pain. > libsodium is not anywhere near the size where static analyses become impractical -- do you have any evidence that would support that? It's not much, but the TweetNaCl papers indicate that its size made it possible to automatically prove the absence of a couple classes of bugs with an algorithm prone to combinatorial explosion. Even being twice as big could have been too much for those.
    - lvh 10y ago
      I'm not suggesting so much that it is painful in general (that's neither here nor there): I'm suggesting that existing libraries, specifically libsodium, make this _easier_ for anyone who isn't writing like C or _maybe_ Rust and _maybe_ Go. (So, anything on the JVM, Python, Javascript, Ruby, PHP... You name it.) For those use cases, the consumed artifact is a .so. Having a .so is easier than having to make it. Furthermore, having repeatedly built libsodium (I built FPM debs when libsodium wasn't yet commonly packaged), for those people building this is just as easy as libsodium if for some reason they need to build at all.
      - loup-vaillant 10y ago
        > Having a .so is easier than having to make it. What's the point, a compilation unit is only a gcc call away from being an .so, right? Besides, I made sure I don't expose unnecessary symbols to the linker. What you're telling me amounts to saying binary distributions are easier to consume than source distributions. I would be quite bewildered by such a claim. As well as a little upset at my disadvantage: I do not have the resources to package my library for all major OSes and distributions. This of course has nothing to do with the library itself, merely the community around it (with one author and no user, as is the case with anything new). I've seen new programming languages being criticised for the immaturity of their tooling or the lack of community. This feels similar. --- Or, your idea of an .so is different from mine. Does .so libraries have something the C source files don't?

by lvh 10y ago

loup-vaillant 10y ago

> allegedly easier to deploy. One .c file, one .h file. No fancy compiler option. It doesn't get any easier. I agree with most of the rest, including the "avoid" recommendation, since Monocypher had only one pair of eyeballs so far. > There are many things I disagree with Please, I need more! (The documentation order was out of laziness, I'll change it.) > using TweetNaCl as a base is less interesting than using libsodium which is both fast and has a lot more eyeballs on it. TweetNaCl is smaller. Much smaller. It doesn't need nearly as many eyeballs as libsodium to reach the same level of confidence. And I'm not sure libsodium had as much audits and static analyses as TweetNaCl, if only because its size may render some analyses impractical. I tried to use ref10 as a base. It's too much code.

lvh 10y ago
I'd disagree with "easier to deploy". Most users are going to do this via FFI, and then one .c and one .h pales in comparison to "already has a dylib/so" I can use. It may be true that it doesn't need as many eyeballs; alternative implementations of the same code have the benefit that they're pretty easy to automatedly check. libsodium is not anywhere near the size where static analyses become impractical -- do you have any evidence that would support that?
- loup-vaillant 10y ago
  > Most users are going to do this via FFI The C interface is the first step. I may consider C++ and OCaml bindings in the future. Still, point taken: calling C from other languages is always a bit of a pain. > libsodium is not anywhere near the size where static analyses become impractical -- do you have any evidence that would support that? It's not much, but the TweetNaCl papers indicate that its size made it possible to automatically prove the absence of a couple classes of bugs with an algorithm prone to combinatorial explosion. Even being twice as big could have been too much for those.
  - lvh 10y ago
    I'm not suggesting so much that it is painful in general (that's neither here nor there): I'm suggesting that existing libraries, specifically libsodium, make this _easier_ for anyone who isn't writing like C or _maybe_ Rust and _maybe_ Go. (So, anything on the JVM, Python, Javascript, Ruby, PHP... You name it.) For those use cases, the consumed artifact is a .so. Having a .so is easier than having to make it. Furthermore, having repeatedly built libsodium (I built FPM debs when libsodium wasn't yet commonly packaged), for those people building this is just as easy as libsodium if for some reason they need to build at all.
    - loup-vaillant 10y ago
      > Having a .so is easier than having to make it. What's the point, a compilation unit is only a gcc call away from being an .so, right? Besides, I made sure I don't expose unnecessary symbols to the linker. What you're telling me amounts to saying binary distributions are easier to consume than source distributions. I would be quite bewildered by such a claim. As well as a little upset at my disadvantage: I do not have the resources to package my library for all major OSes and distributions. This of course has nothing to do with the library itself, merely the community around it (with one author and no user, as is the case with anything new). I've seen new programming languages being criticised for the immaturity of their tooling or the lack of community. This feels similar. --- Or, your idea of an .so is different from mine. Does .so libraries have something the C source files don't?