[cryptography] "Combined" cipher modes
noloader at gmail.com
Mon Feb 20 14:58:23 EST 2012
On Mon, Feb 20, 2012 at 7:11 AM, ianG <iang at iang.org> wrote:
> On 20/02/12 18:11 PM, Kevin W. Wall wrote:
>> Hi list,
>> This should be a pretty simple question for this list, so please pardon
>> my ignorance. But better to ask than to continue in ignorance. :-)
>> NIST refers to "combined" cipher modes as those supporting *both*
>> authenticity and confidentiality, such as GCM and CCM.
> My personal impression of such things is that although they can give a paper
> sense of authenticity, it is not good enough to rely on at an application
> level because of software layering issues. In the past, I've preferred to
> use a heavyweight signed plaintext packet, then encrypted with a light-level
> HMAC or similar. So, yes it is authenticated twice, but they are at
> different strengths / semantics / layers.
>> So my first question: Are there ANY "combined" cipher modes
>> for block ciphers that do not cause the ciphers to act as a key
>> stream? (That seems to be cause most of the ones I found build
>> the confidentiality piece around CTR mode.) If "yes", please name
>> a few (especially those with no patent restrictions).
>> I know when you have a cipher that acts in a streaming mode,
>> that you need to be careful to use a unique IV for every encryption
>> performed with the same key.
> Well. With basic modes like CBC, if there is no variation in the early
> parts of the packet, those blocks will encrypt the same.
> A good plaintext packet design can push strong variation into the first
> bytes. e.g., the MAC can go at the beginning not the end. It used to be
> customary to put the MAC at the end because hardware calculated it and
> streamed it at the same time, but software doesn't work that way.
> (There was a paper suggesting that encrypt-then-mac was better than
> mac-then-encrypt, but I vaguely recall this result only applies under some
> circumstances. Does anyone recall how important this issue was?)
I believe MAC-the-Encrypt (or Authenticate then Encrypt, AtE) could
suffer extension attacks. I also seem to recall it requires the server
to sign messages for you under one attack (which is a bit contrived).
But I'm more than willing to concede there are a lot of bright folks
out there, many of whom can easily devise an attack I lacked the
foresight to see.
As for which is better, EtA or AtE, I generally cite Hugo Krawczyk's
"The Order of Encryption and Authentication for Protecting
More information about the cryptography