Re: CRC32 - thoughts on Gutmann response

Personally, I wouldn't mind if a protocol committee was formed once someone 
finds Olaf. I hope he's on vacation or something.

DKW

On Thursday 25 September 2003 11:59 am, Allan Latham wrote:
> 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 days.
>
> 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!
>
> Allan
>
> PS scrambling the entire payload before running CBC on it is worth doing as
> it 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),
>
> --
> Message sent by the [email protected] mailing list.
> Unsubscribe: mail [email protected], "unsubscribe cipe-l" in body
> Other commands available with "help" in body to the same address.
> CIPE info and list archive:
> <URL:http://sites.inka.de/~bigred/devel/cipe.html>


--
Message sent by the [email protected] mailing list.
Unsubscribe: mail [email protected], "unsubscribe cipe-l" in body
Other commands available with "help" in body to the same address.
CIPE info and list archive: <URL:http://sites.inka.de/~bigred/devel/cipe.html>