Re: Maybe we only need PCBC...

From: Andrew Swallow (am.swallow_at_eatspam.btinternet.com)
Date: 06/30/03 

Date: Mon, 30 Jun 2003 00:15:15 +0000 (UTC)

"Tom St Denis" <tomstdenis@iahu.ca> wrote in message
news:vmsLa.5493$2ay.2444@news01.bloor.is.net.cable.rogers.com...
> jsavard@ecn.ab.ca wrote:
> > It occurred to me that my recent invention, PCC mode encryption, even
> > though it is much simpler than other integrity-aware schemes, instead of
> > being what the world is looking for, may still be overly complex.
> >
> > PCBC mode encryption was one of the first attempts at an integrity-aware
> > encryption mode. But it had a defect; one could exchange blocks, and
then
> > the result would be to garble a small portion of the message, with the
> > rest remaining intact.
> >
> > My proposed PCC mode wasn't just an encryption mode; it was accompanied
by
> > simple CRC checksums that were encrypted at the end. So it didn't rely
on
> > *just the mode* for integrity; the mode of encryption made it possible
to
> > get away with using a checksum that was not collision-resistant.
> >
> > But since the only defect in PCBC is the ability to make *uncontrolled
> > garbles*, it follows that if one adds a CRC checksum to PCBC, the result
> > is, as far as is currently known, secure. Thus, the extra elaboration of
> > my PCBC-CTR-CBC mode is not required.
>
> CRC's are linear though. I wouldn't trust such a construction off hand.
>
CRC checksums are designed to handle low to medium error rates
generated by natural causes. Encrypting both the packet and the
checksum makes successfully performing undetected changes to
message difficult providing the CRCs location is also hidden.

A factor to remember is that total corruption of the message can
fool the CRC checker. CRC16 will pass 1 out of every 65,536
incorrect packets on a high error link. CRC32 can survive
4,294,967,296 incorrect packets.

Andrew Swallow