Authenticated Encryption(blog.woobling.org)
blog.woobling.org
Authenticated Encryption
http://blog.woobling.org/2009/10/authenticated-encryption.html
6 comments
Another "leave it to the experts to handle the encryption details" effort is Google Keyczar:
http://www.keyczar.org/
Here's some sample code in python:
http://code.google.com/p/keyczar/wiki/SamplePythonUsage
http://www.keyczar.org/
Here's some sample code in python:
http://code.google.com/p/keyczar/wiki/SamplePythonUsage
And the experts have a hard time of it too:
http://rdist.root.org/2009/05/28/timing-attack-in-google-key...
http://groups.google.com/group/keyczar-discuss/browse_thread...
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.
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.
On the other hand, there is more public code implementing HMAC than there is for EAX.
Yes, they're certainly faster than HMAC.
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.
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.
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".