On Mon, Feb 20, 2012 at 7:11 AM, ianG <[email protected]> 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 Communications," http://www.iacr.org/archive/crypto2001/21390309.pdf. Jeff _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
