----- Original Message -----
From: "Nikita Borisov" <[EMAIL PROTECTED]>
Newsgroups: isaac.lists.cryptography
To: <[EMAIL PROTECTED]>
Sent: Friday, December 15, 2000 6:56 AM
Subject: Re: IBM press release - encryption and authentication
> In article <010801c064d0$b64193a0$6000a8c0@em>,
> Enzo Michelangeli <[EMAIL PROTECTED]> wrote:
> >Apart from the parallelization-friendliness, wouldn't the same result be
> >achieved by encrypting the concatenation of the plaintext with a MAC
> >implemented through a fast error detection code (say, a sufficiently long
> >CRC)? Due to the presence of encryption, the security properties of the
> >inner MAC don't appear to really matter (as they would in the "DES-CBC
> >first, then HMAC-MD5" scenario mentioned in the draft for comparison).
>
> 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.
Unfortunately I have no access to the paper you mention, but I was really
thinking more in terms of MIC than MAC. In a scenario purely based on
symmetric algorithms, both encryption and authentication rely on the fact
that Bob and Alice share a secret (encryption key and key used to compute
the MAC). If both operations are performed at the same time, it makes sense
to use only one key reducing the MAC to a MIC, as long as the recipient has
a way of recognizing the decrypted plaintext as valid, distinguishing it
from random garbage produced by an attempt of decryption with the wrong key.
In other words, authentication is reduced to integrity check.
But now, it seems to me (and I may well be wrong) that the fact that both
message and MIC are encrypted makes it impossible for an attacker to play
the tricks that normally make a simple CRC insecure requiring the use of
secure (but slow) hashes. So, a simple and fast error correction code should
do the job.
OpenPGP tries to detect such "wrong key" situations for
symmetrically-encrypted packets in a pretty simplistic way, by repeating two
of the eight random bytes used to prefix the plaintext (incidentally, this
means that there is a non negligible chance of these cases going
undetected...). From the section 5.7 of RFC2440:
[...]
The data is encrypted in CFB mode, with a CFB shift size equal to the
cipher's block size. The Initial Vector (IV) is specified as all
zeros. Instead of using an IV, OpenPGP prefixes a 10-octet string to
the data before it is encrypted. The first eight octets are random,
and the 9th and 10th octets are copies of the 7th and 8th octets,
respectively. After encrypting the first 10 octets, the CFB state is
resynchronized if the cipher block size is 8 octets or less. The
last 8 octets of ciphertext are passed through the cipher and the
block boundary is reset.
The repetition of 16 bits in the 80 bits of random data prefixed to
the message allows the receiver to immediately check whether the
session key is incorrect.
[...]
Enzo
