5 ms·

You have a good point, but it's still suggesting that you can implement CBC correctly without a good IV.

tptacek 15y ago
I think you're making a "gotcha" point. It's impossible to implement any crypto protocol safely with ECB mode. And yet libraries far more popular than this one aren't subject to blog posts dinging them for being "broken by default". I actually agree with you that not requiring an explicit IV is a bad interface choice. On the other hand, I'm appalled by the idea of any library that exposes AES directly to applications anyways. There's a myriad of mistakes developers make using AES directly. CBC IVs are not among the top three.
- marshray 15y ago
  It's impossible to implement any crypto protocol safely with ECB mode. But ECB mode may be a useful primitive component of some other, more secure, mode. For example, this API doesn't support CTR mode, but if you needed it, probably the most efficient thing would be to fill a buffer with your nonce and counter values pass it to this API to be encrypted using "ECB mode". It's parallelizable that way. And that is the point of this level of crypto API: providing efficient access to whatever software implementation or hardware acceleration may be available on the target system. And yet libraries far more popular than this one aren't subject to blog posts dinging them for being "broken by default". I want to give Nadim some credit here: he is thinking like an attacker now! This represents a great improvement over his previous crypto implementation endeavors.
  - tptacek 15y ago
    Sure. But I'm not talking about the availability of ECB; I'm talking about ECB as a default. And, I agree with the fundmental point he's making: optional IVs for CBC mode are a bad interface details for lay programmers. Just remember, every AES library makes similar (usually worse) design mistakes. Generalists are very poorly served by low-level AES libraries (where "low level" certainly includes any library where you have to think about IVs or, indeed, which block cipher mode to use).
- SoftwareMaven 15y ago
  I'd love to see that list. I'm sure not generating MACs is on there. I could imagine reusing keys could be there. What else?
- rdl 15y ago
  This is a pretty good visual argument against ECB (the image): http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Electronic_codebook_.28ECB.29 http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation...

I think you're making a "gotcha" point. It's impossible to implement any crypto protocol safely with ECB mode. And yet libraries far more popular than this one aren't subject to blog posts dinging them for being "broken by default". I actually agree with you that not requiring an explicit IV is a bad interface choice. On the other hand, I'm appalled by the idea of any library that exposes AES directly to applications anyways. There's a myriad of mistakes developers make using AES directly. CBC IVs are not among the top three.

marshray 15y ago
It's impossible to implement any crypto protocol safely with ECB mode. But ECB mode may be a useful primitive component of some other, more secure, mode. For example, this API doesn't support CTR mode, but if you needed it, probably the most efficient thing would be to fill a buffer with your nonce and counter values pass it to this API to be encrypted using "ECB mode". It's parallelizable that way. And that is the point of this level of crypto API: providing efficient access to whatever software implementation or hardware acceleration may be available on the target system. And yet libraries far more popular than this one aren't subject to blog posts dinging them for being "broken by default". I want to give Nadim some credit here: he is thinking like an attacker now! This represents a great improvement over his previous crypto implementation endeavors.
- tptacek 15y ago
  Sure. But I'm not talking about the availability of ECB; I'm talking about ECB as a default. And, I agree with the fundmental point he's making: optional IVs for CBC mode are a bad interface details for lay programmers. Just remember, every AES library makes similar (usually worse) design mistakes. Generalists are very poorly served by low-level AES libraries (where "low level" certainly includes any library where you have to think about IVs or, indeed, which block cipher mode to use).
SoftwareMaven 15y ago
I'd love to see that list. I'm sure not generating MACs is on there. I could imagine reusing keys could be there. What else?
rdl 15y ago
This is a pretty good visual argument against ECB (the image): http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Electronic_codebook_.28ECB.29 http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation...