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?)
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:
random||counter||time
With most algorithms these days, you've got 16 bytes in the first block.
Thanks,
-kevin
iang
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
