Ray Dillinger writes:
>>I may be misunderstanding what you are suggesting, but the construction
>>that uses an encrypted CRC as a MAC is insecure. Eg. Stubblebine &
>>Gligor[1] show attacks on protocols which encrypt the concatenation of a
>>packet and a CRC-32 using DES-CBC. The properties of the MAC, encrypted
>>or not, do appear to matter.
>
>Yeah. The problem with an encrypted CRC is that it's relatively
>easy to find another plaintext that has the same CRC, hence you
>can substitute a different set of bits for the document.
Actually, there are problems even if you use a function that does not
have this property. There is a general attack, which David Wagner just
pointed out to me, that applies even if we use a collision-resistant
hash function instead: suppose your authenticating code is
encrypt(m||H(m)), where H is a hash function. Then there is a
chosen-message attack that asks the sender to encrypt&authenticate the
message m=m'||H(m')||pad. Then, by taking a prefix of the message, the
attacker has a valid authentication on the message m'. Now, this is a
bit of an esoteric attack, but it does violate the security conditions
of a MAC.
My point is that a CRC, or even an unkeyed hash function, does not
guarantee authenticity, only integrity. Similarly, encrypting something
does not guarantee authenticity, only secrecy, because it may be
possible to get an encryption of what you want in a different context.
Jutla's proof of security goes to some length to ensure that this does
not occur with reasonable probability.
- Nikita
