Re: CRC32 - thoughts on Gutmann response

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),
--
There's an excellent C/C++/Python/Unix/Linux programmer with a wide
range of other experience and system admin skills who needs work.
Namely, me. http://www.omnifarious.org/~hopper/resume.html
-- Eric Hopper <[email protected]>

-----BEGIN PGP MESSAGE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD4DBQA/cv82jtsvlOwvazYRApbhAKDPTj+fl5+SyOU6mOrBHVx5vShZiACWOs6r
/UU7Q/bd4C+op2Ee952yZQ==
=LexF
-----END PGP MESSAGE-----