4 ms·

https://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.ncc

https://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 ago
The 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.
  - Cyph0n 10y ago
    * Never said AES ECB was an alternative to DES. * 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.
    - tptacek 10y ago
      I'm not offended that you didn't like the article. I'm saying you failed to summarize it. I'm pretty sure I know what the point of this particular article was. :)
      - Cyph0n 10y ago
        OK, fair enough.
    - CiPHPerCoder 10y ago
      > * Never said AES ECB was an alternative to DES. > 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 Yes, a privileged few are actually capable of cobbling together a secure cryptosystem out of AES, HMAC, SHA2-family hash functions, and maybe Ed25519 and X25519 if they have a sane implementation available. The general public should just use whatever AEAD mode they're provided and not build their own disaster. > * 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-know-about-hash-length-extension-attacks 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.
      - Cyph0n 10y ago
        And I thought I couldn't have gotten a worse response! Good job :)

Cyph0n 10y ago

The 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.
- Cyph0n 10y ago
  * Never said AES ECB was an alternative to DES. * 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.
  - tptacek 10y ago
    I'm not offended that you didn't like the article. I'm saying you failed to summarize it. I'm pretty sure I know what the point of this particular article was. :)
    - Cyph0n 10y ago
      OK, fair enough.
  - CiPHPerCoder 10y ago
    > * Never said AES ECB was an alternative to DES. > 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 Yes, a privileged few are actually capable of cobbling together a secure cryptosystem out of AES, HMAC, SHA2-family hash functions, and maybe Ed25519 and X25519 if they have a sane implementation available. The general public should just use whatever AEAD mode they're provided and not build their own disaster. > * 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-know-about-hash-length-extension-attacks 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.
    - Cyph0n 10y ago
      And I thought I couldn't have gotten a worse response! Good job :)