7 ms·
> Use a well-known secure algorithm (AES256 is considered the standard). > Never roll your own crypto. Directly using a primitive like AES is pretty much roll
by floatboth 10y ago
> Use a well-known secure algorithm (AES256 is considered the standard).
> Never roll your own crypto.
Directly using a primitive like AES is pretty much rolling your own crypto. (Creating an actual cipher and using it is just beyond ridiculous.)
What you should use is secretbox from NaCl (libsodium or tweetnacl). Or Keyczar, I guess that's still maintained (last commit on github is 21 days ago). Or TripleSec for long term things that you're really really paranoid about.
The point is, use a library that does authenticated encryption for you.
- tptacek 10y agoIt's exactly rolling your own crypto. This is the second thread today on which someone has had to point this out (thanks!). Virtually nobody writes their own ciphers. But "Don't roll your own crypto" is still important and still very common advice. Why? Because the stuff you do to actually apply "AES256" to your data is the stuff that actually causes crypto vulnerabilities. In fact: if you do some reading on modern stream ciphers and design your own stream cipher, and then plug that cipher into libsodium, you are probably more secure than you would be if you tried to use AES256 in your own library without libsodium!
- tonyhb 10y agoYep. I've used NaCl for edwardian curves using djb's boxes and it's pretty much ideal as far as I'm concerned.
- tptacek 10y agoEdwards curves, not Edwardian. They didn't have those curves in 1905. Curve25519 isn't an Edwards curve. Ed25519 is the equivalent Edwards curve. Curve25519 is a Montgomery curve. NaCL uses C25519 for DH, and Ed25519 for signing. I'm just responding to the nerd snipe (and eagerly awaiting my comeuppance from 'pbsd). You're right (in advance) that the point of using NaCL is that you don't need to know any of this trivia.
- Cyph0n 10y agoWhy is using AES-256 directly considered "bad"? Is the issue key management? RNG? Padding? Or what exactly? Genuine question. Or do you mean that re-implementing AES-256 in your own library instead of using a well-tested implementation is "bad"?
- greendragon 10y agohttps://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2009/july/if-youre-typing-the-letters-a-e-s-into-your-code-youre-doing-it-wrong/ https://www.nccgroup.trust/us/about-us/newsroom-and-events/b...
- Cyph0n 10y agoThe context of the long-winded conversation you linked to is user auth and session cookies. That's a VERY specific use case for AES. I'm talking about AES in general. But I still skimmed through it. TL;DR * AES CBC instead of ECB or (gasp) Triple DES * SHA-1 instead of MD5 * Use MACs * Be careful with padding
- tptacek 10y ago* ECB is not an alternative to 3DES * If you use 3DES or any other 8-byte block cipher you import several additional security concerns you have to code around * If you use CBC you also have to get the IV right, which tons of carefully designed crypto has failed to do * SHA-1 is also insecure * Neither MD5 nor SHA-1 is a MAC * Your choice of MACs brings with it new security pitfalls * How you apply the MAC also has pitfalls; see, for instance, all the systems that have managed to leave CBC IVs out, because they were specified as separate arguments * Padding is a pitfall if you use CBC... or a few other modes --- guess which! * If you use something other than CBC you get other pitfalls * "Be careful with padding" is a vague description of like 6 different padding vulnerabilities you have to know about * You still haven't even generated a key yet * In the unlikely event you get all of this right, all you've managed to do is write a very basic symmetric key seal/unseal --- you're still only 40% of the way (in functional terms) to something as simple as NaCL So, no, I would not say that was the TL;DR of that piece. I think the TL;DR of that piece is right there in the title.