[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CBCC
Bill:
Some people will object to CBCC because it is not available in today's
hardware implementations. Other than that concern, I know of no reason to
avoid CBCC.
You could calculate a CRC on the whole payload, then place the resulting
CRC value in the final block of the payload. The CBCC XORing will ensure
that the CRC does not decrypt correctly if the ciphertext is twiddled.
Russ
______________________________ Reply Separator _________________________________
Subject: CBCC
Author: bsimpson@morningstar.com at internet
Date: 9/1/94 6:57 PM
> From: "Housley, Russ" <housley@spyrus.com>
> Of course, this is correct. The tricky part is, as you say, "if
> the encryption is strong and the probability of garbage passing the
> integrity check is low enough." Xerox did some work in this area that
> resuted in a little known DES mode - Cipher Block Chaining with Checksum
> (CBCC). At the expense of one additional XOR per 64-bit data block, a sum
> of the ciphertext data blocks is kept. Then, this sum is used in the
> encryption (and decryption) of the final data block. CBCC ensures that
> changes made to any ciphertext block impact the decrypted output of the
> last block. If the last block contains an integrity check (like a CRC) or
> a constant, then integrity can be checked with very little additional
> overhead. Certainly much less overhead than MD5, epsecially if a constant
> is used.
>
Sounds like this is the way to go for our default encryption technique.
Why the XOR? Why not CRC over the whole payload, appended to the end of
the final block before encryption? CRC-32 isn't _that_ expensive,
especially compared to CBC.
Bill.Simpson@um.cc.umich.edu