<< | Thread Index | >> ]    [ << | Date Index | >> ]

To: cipe-l,AT,inka,DOT,de
Subject: Re: CRC32 - thoughts on Gutmann response
From: Allan Latham <alatham,AT,flexsys-group,DOT,com>
Date: Thu, 25 Sep 2003 16:59:49 +0200
In-reply-to: <1064501046.7652.112.camel@monster.omnifarious.org>
References: <200309241259.44433.rsmckown@yahoo.com> <200309251610.26588.alatham@flexsys-group.com> <1064501046.7652.112.camel@monster.omnifarious.org>

Hi Eric

given that it's just as easy to generate a secure hash as a 32 bit csum then 
this should certainly be implemented. The extra length is not an issue these 

I am however pleading for a reasonable view - if you are clever enough to 
toggle bits in the CRC and the IP length and IP csum and the TCP csum and 
still keep the TCP stream in step then there are any number of three letter 
agencies who would employ you immediately!

> Have fun (if at all possible), - certain do!


PS scrambling the entire payload before running CBC on it is worth doing as 
means there is no known plaintext anywhere in the packet - it mean some extra 
key material is needed but I would like to see that done if anyone is going 
to implement any of these changes.

On Thursday 25 September 2003 16:44, Eric M. Hopper wrote:
> On Thu, 2003-09-25 at 09:10, Allan Latham wrote:
> > The CIPE payload is an IP packet and is subject to further integrity
> > checks before the application receives it. At a minimum the IP lengths
> > and csum must be OK. In a real application the UDP or TCP csums must also
> > be OK. In the case of TCP there is also the stream position information
> > which needs to be correct.
> I would agree if any of the integrity checks that TCP, UDP, and IP used
> were cryptographically secure, but in fact they are not.  Sure they're
> encrypted, but CBC has known ways of messing with individual bits in
> encrypted messages.  Since the integrity checks in TCP, UDP, and IP
> aren't cryptographically secure, and in fact have a very simple, easily
> manipulated algebraic structure, they are vulnerable to such
> manipulations.
> Prudence dictates that somewhere in your protocol, the important stuff
> is protected using a cryptographically secure integrity protection
> technique.
> Implementing such a technique is not hard, and would not add appreciably
> to code size or complexity.  I've done it for a protocol I'm designing.
> The biggest drivers of complexity in cryptographic protocols are options
> and the option negotiation they make neccessary.
> I don't care if there's a working exploit or not.  Any possibility at
> all that bits can be fiddled without an obvious, tight constraint on
> such fiddling is something that should be fixed.  Neither CRC-32, nor
> TCP/UDP/IP header and data checksum or length fields provide such a
> constraint.  Relying on CBC to provide part of your integrity protection
> isn't good design.
> > Effect of CRC32 in the key exchange mechanism:
> >
> > I have not studied this further but if I get a little time I will review
> > that too along with other points raised.
> Actually, I'm more concerned with the possibility of replay attacks on
> the key exchange mechanism.  For a cipher with no weak keys, the bit
> fiddling possibilities afforded to you by the use of CRC-32 don't seem
> to be a big issue.  But, if you're going to use HMAC for the rest of the
> packets, then it would be senseless not to use it for the key exchanges
> as well.
> > I stand by my point that program complexity and the associated bugs -
> > especially in closed source products - are the major real threat.
> I agree that they are a much greater threat.
> Have fun (if at all possible),

<< | Thread Index | >> ]    [ << | Date Index | >> ]