4 ms·

There's a few different "just trust us" mentalities, but I've become more comfortable with the "don't roll your own if you missed the first 10 minutes of the le

There's a few different "just trust us" mentalities, but I've become more comfortable with the "don't roll your own if you missed the first 10 minutes of the lecture" worldview. Separating algorithm from implementation seems like it shouldn't be so difficult, but retrospect is a great teacher. So now we have approaches like NaCl, where the algorithms are designed to be hard to implement badly. And we have projects like LibTom, which aims to implement existing algorithms clearly. Both seem to be enjoying varying degrees of success.

deleted 13y ago
[deleted]
tptacek 13y ago
NaCl is designed to be user-proof. Part of its appeal is that it uses state-of-the-art primitives and constructions, but the reason it's so widely recommended, and the thesis behind its design, is that it's hard to misuse. The same isn't true of LibTomCrypt. Use NaCl. Be very, very careful with LibTomCrypt.
- dvanduzer 13y ago
  Hmm. I was definitely oversimplifying, but if I need AES-256-GCM, how do I choose between OpenSSL and LibTom? (If you have particular insight into the strength of LibTom's GCM table acceleration implementation, I'm quite curious.) What multiplication factor on "very" careful do I need to be with OpenSSL? :) edit: Maybe I should've posted this link[0], because tables vs CLMUL is a little more complicated than that. [0] https://github.com/pyca/cryptography/issues/846 https://github.com/pyca/cryptography/issues/846
  - tptacek 13y ago
    IIRC, LibTom is table-driven, and OpenSSL will use CLMUL, so I'd have to give GCM to OpenSSL.