Allan Latham <alatham,AT,flexsys-group,DOT,com>|
Re: CRC32 - thoughts on Gutmann response|
Damion Wilson <dwilson,AT,ibl,DOT,bm>|
Thu, 25 Sep 2003 19:25:26 -0300|
<email@example.com> <firstname.lastname@example.org> <email@example.com>|
Personally, I wouldn't mind if a protocol committee was formed once someone
finds Olaf. I hope he's on vacation or something.
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!
> 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 cipe-l,AT,inka,DOT,de mailing list.
> Unsubscribe: mail majordomo,AT,inka,DOT,de, "unsubscribe cipe-l" in body
> Other commands available with "help" in body to the same address.
> CIPE info and list archive: