I think interfaces like this are a step in the right direction, not because they're likely to be correct, but because there's only one implementation to get correct instead of thousands.
The AE modes --- CCM, EAX, and GCM being the most popular --- are your safest bet when picking a block cipher mode. But ask yourself: if you're being asked to think about what a block cipher mode is, are you working at the right level of abstraction? For instance: we've beat CCM constructions that couldn't properly generate a nonce at cold start (you combine a flaw like that with a crasher bug and you have a weaponizable attack), and we've seen CCM schemes whether the counter didn't have enough granularity and could be forced to wrap, which can make your scheme vulnerable to pencil-and-paper attacks.
Do you know what I'm talking about here? If not, that's kind of my point.
I really appreciate anybody who takes the time to point out that encryption is not the same as authentication, and that you have to do both to make a system secure. And I really appreciate anybody who evangelizes for a high-level interface, as opposed to one where you have to know that you're encrypting byte-by-byte (EAX) instead of block-by-block (CBC).
I still think the soundest advice you can get is, "rely on TLS if you're moving data, and rely on PGP/GPG if you're storing it; if you have a problem that doesn't fit these perfectly, refactor your problem".
That's exactly why I wrote Crypt::Util... Generating, and worse, transferring a nonce is annoying each time, so Crypt::Util just generates one unless explicitly told not to, and includes it in the ciphertext.
By being lazier (using a convenience wrapper) I have no choice but to do it right (unless I try hard), whereas if I'm too lazy to generate a nonce and put in a #FIXME i'm likely to forget it.
Unfortunately we still have to "trust" the ciphertext at least to extract the nonce, that's what my comment about 64KiB was about.
I totally agree that "refactor your problem" should be the MO for anyone trying to use crypto, but it's a little idealistic.
The problem with TLS and PGP is that they require public key cryptography, which requires key management, at least to some extent. That can add a lot of complexity to the app, even if that's not part of the domain, you often need to expose key management decisions to the user.
Secondly, a large number of people still don't understand public key encryption. Hell, they don't understand shared key encryption. Even roll-your-own managed code type software is completely flawed by design but still makes scammers a living. Technically it's no different than obfuscation (the key is in the encrypted data as metadata, after all).
TLS/GPG is hard to use, even if you're more likely to use it right if you succeed. You not only need to understand the concepts behind public key cryptography at the high level, but the low level too (the semantics of the trust models, for instance), and on top of that the engineering constraints (generating SSL certs is still a bit of a dark art).
Back on the topic of this thread:
Keyczar authenticates all symmetric ciphertexts by default. However, it HMACs the output, rather than using one of the authenticated cipher modes.
HMAC is definitely slower and might be less secure than the MAC functions used by the AE modes, which (especially with CCM and EAX) are based on AES instead of hash functions.
On the other hand, there is more public code implementing HMAC than there is for EAX.
I've found that OCB is faster than CCM or EAX because it's only one pass, but unfortunately is patented. It can be used under the GNU GPL, though.
Phil Rogaway considers EAX to have been "supplanted by SIV". I'm not sure if I agree with that, but do like SIV for applications requiring deterministic, authenticated output with tight length overhead.
6 comments
[ 5.0 ms ] story [ 24.0 ms ] threadThe AE modes --- CCM, EAX, and GCM being the most popular --- are your safest bet when picking a block cipher mode. But ask yourself: if you're being asked to think about what a block cipher mode is, are you working at the right level of abstraction? For instance: we've beat CCM constructions that couldn't properly generate a nonce at cold start (you combine a flaw like that with a crasher bug and you have a weaponizable attack), and we've seen CCM schemes whether the counter didn't have enough granularity and could be forced to wrap, which can make your scheme vulnerable to pencil-and-paper attacks.
Do you know what I'm talking about here? If not, that's kind of my point.
I really appreciate anybody who takes the time to point out that encryption is not the same as authentication, and that you have to do both to make a system secure. And I really appreciate anybody who evangelizes for a high-level interface, as opposed to one where you have to know that you're encrypting byte-by-byte (EAX) instead of block-by-block (CBC).
I still think the soundest advice you can get is, "rely on TLS if you're moving data, and rely on PGP/GPG if you're storing it; if you have a problem that doesn't fit these perfectly, refactor your problem".
By being lazier (using a convenience wrapper) I have no choice but to do it right (unless I try hard), whereas if I'm too lazy to generate a nonce and put in a #FIXME i'm likely to forget it.
Unfortunately we still have to "trust" the ciphertext at least to extract the nonce, that's what my comment about 64KiB was about.
I totally agree that "refactor your problem" should be the MO for anyone trying to use crypto, but it's a little idealistic.
The problem with TLS and PGP is that they require public key cryptography, which requires key management, at least to some extent. That can add a lot of complexity to the app, even if that's not part of the domain, you often need to expose key management decisions to the user.
Secondly, a large number of people still don't understand public key encryption. Hell, they don't understand shared key encryption. Even roll-your-own managed code type software is completely flawed by design but still makes scammers a living. Technically it's no different than obfuscation (the key is in the encrypted data as metadata, after all).
TLS/GPG is hard to use, even if you're more likely to use it right if you succeed. You not only need to understand the concepts behind public key cryptography at the high level, but the low level too (the semantics of the trust models, for instance), and on top of that the engineering constraints (generating SSL certs is still a bit of a dark art).
http://www.keyczar.org/
Here's some sample code in python:
http://code.google.com/p/keyczar/wiki/SamplePythonUsage
Back on the topic of this thread: Keyczar authenticates all symmetric ciphertexts by default. However, it HMACs the output, rather than using one of the authenticated cipher modes.
On the other hand, there is more public code implementing HMAC than there is for EAX.
I've found that OCB is faster than CCM or EAX because it's only one pass, but unfortunately is patented. It can be used under the GNU GPL, though.
Phil Rogaway considers EAX to have been "supplanted by SIV". I'm not sure if I agree with that, but do like SIV for applications requiring deterministic, authenticated output with tight length overhead.