5 ms·

Isn't libsodium the library to use?

• ilammy 4y ago
  If you're writing an application, you'd better off with a library even higher on the abstraction layer. The one the abstracts away the choice of specific cryptographic primitives. Without being a domain expert your choices might end up subpar, your use of primitives might end up subpar, your attention to detail might end up subpar, etc. Also, it would be nice to talk to experts in security, since choosing a library and choosing a curve is a very small part of it. You'd have way more ways to fuck up, say, key management, or miss a glaring hole in some other place of your system.
  • some_furry 4y ago
    This is precisely what I recommend in my "how to learn cryptography as a programmer" post. https://soatok.blog/2020/06/10/how-to-learn-cryptography-as-a-programmer/ https://soatok.blog/2020/06/10/how-to-learn-cryptography-as-... Start with the highest-level, hard-to-get-wrong abstraction. If you stop learning there, you're safe! Then drill down as you be come more of an expert. Libsodium is step 2 from something fit-for-purpose.
• matthewdgreen 4y ago
  That would be my intuitive recommendation, but canvassing experts I haven't found a clear recommendation across all languages. Some have recommended Tink, others have recommended (ugh) OpenSSL. Javascript is particularly fraught: is it better to use libsodium compiled via emscripten, or something native? It's depressing that we don't have agreement here.
  • some_furry 4y ago
    Maybe I'll write about that next ;) For JavaScript: emscripten/wasm/etc. don't currently provide constant-time guarantees, so you're better off using the native crypto module.