Why 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"?
Or do you mean that re-implementing AES-256 in your own library instead of using a well-tested implementation is "bad"?
https://github.com/search?utf8=%E2%9C%93&q=aes+encryption
I'm not going to call out any project by name, but on the first few pages, I see:
- A project which implements unauthenticated CBC mode AES
- A project that does not, in any way, document its mode or implementation beyond "using AES 256"
- A project with <10 commits, more than two years ago, yet over 50 stars
- A project that uses mcrypt
Over all, it is easier to find a project with horrible deficiencies than anything that didn't immediately look concerning. And every one of these boasts "AES 256 encryption".
https://paragonie.com/blog/2015/05/if-you-re-typing-word-mcr...
Problem #2 is something I've hit in multiple real-world codebases.
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
* 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.
* I would never use 3DES.
* I am aware of that, just TLDRing. SHA-256 is my cup of tea.
* Did I say they were a MAC? I would use CBC HMAC + SHA-256 for that.
* No idea, since I'm not an expert at AES.
I feel like you're offended that I didn't like the article. It's just an opinion, don't take it personally.
> AES CBC instead of ECB or (gasp) Triple DES
What? This entire vein of conversation is nothing but miscommunication.
These are two choices a developer should use:
* crypto_secretbox() and crypto_secretbox_open()
from NaCl or libsodium
* rm -rf code/ && shutdown
> * I would never use 3DES.
Good.
> * I am aware of that, just TLDRing. SHA-256 is my cup of tea.
SHA-384 is mine.
https://blog.skullsecurity.org/2012/everything-you-need-to-k...
Except for passwords. You don't use simple hash functions for passwords.
> * Did I say they were a MAC? I would use CBC HMAC + SHA-256 for that.
I'm assuming you meant AES-CBC + HMAC-SHA-256 here, in an encrypt-then-authenticate mode.
By "assuming" I of course meant "hoping".
> * No idea, since I'm not an expert at AES.
AES expertise isn't the issue here. Composing a secure cryptography protocol out of standard implementations is a rare skill set among software engineers.