[cryptography] "Combined" cipher modes
iang at iang.org
Mon Feb 20 07:11:55 EST 2012
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 /
> 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?)
> So my second question is, if all the "combined" cipher modes all
> cause a cipher to act as if it is in a streaming mode, is it okay
> to just choose a completely RANDOM IV for each encryption?
> Because it sure doesn't seem to be feasible to record all the IVs
> for a given key to make sure that an IV isn't reused. If that is not
> acceptable, then how does one ever address this?
Random is good. Also, using a counter that always goes up is good.
Another possibility is to use a sufficiently fine timesource.
All of these devices look good on paper but have some edge cases. One
way is to cram them all into the IV as one lump:
With most algorithms these days, you've got 16 bytes in the first block.
More information about the cryptography