[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: compression, privacy, and authenticity transforms
Hugo:
>> I strongly disagree. We can take advantage of the properties of the
>> encryption algorithm and mode to reduce the requirements on the complexity
>> of the integrity mechanism iff the integrity check value is protected by
>> the encryption. This also means that one key can be used to provide
>> confidentiality and integrity.
>>
>> The reduced computation and reduced key management complexity make this
>> type of combination very attractive.
>
> Russ, can you explain *exactly* how are you going to take advantage of the
> compression together with encryption in order to provide for *secure*
> integrity check?
>
> This issue of using key-less algorithms (CRC, non-cryptographic checksums,
> etc.) to provide integrity was extensively discussed in the past in this
> WG and fortunately abandoned due to the existing evidence that these
> schemes are insecure. This new (?) idea of using compression with
> encryption for that purpose is as unacceptable as the above ones.
Hugo, please reread my original message. I did not say anything about
compression. Aside from that nit pick, I will demonstrate an example of a
confidentiality mechanism and a keyless integrity mechanism being used
together in a pairwise (not multicast) scenario.
As pointed out by Colin, the CRC is not appropriate for this environemnt.
However, another integrity check value (ICV) might be more compatible with
DES CBC. I found an example where one's complement addition and a constant
are used together.
Before encryption, an ICV is appended to the data. The ICV is 64 bits long
(and thus does not change the pad requirement). The first 32 bits are a
checksum: the one's complement sum of all of the 32-bit words in the
packet. The second 32 bits are all zero. Upon decryption, the recipient
checks that the second 32 bits of the ICV are zero. If they are, then the
checksum is computed. If the received checksum is the same as the computed
checksum, then the ICV check passes.
Unlike the MIT PCBC or Xerox CBCC, the technique discussed above adds a
check value prior to encryption. I know that the MIT PCBC, Xerox CBCC, and
DES with CRCs were shown to be insufficient, but I missed something if
there is a problem with the technique discussed above.
Clearly, a keyed ICV would be even stronger, but I am hoping to avoid the
key management complexity of an additional key.
Russ