CRC32 - thoughts on Gutmann response

[Allan Latham <alatham,AT,flexsys-group,DOT,com>]

Hi all

Let us look at the CRC32 csum in the context of an eavesdropper:

It provides known plaintext in as much as it must be the CRC32 of the rest of 
the packet. Other parts of the packet are known to a high probability as it 
is an IP payload.

My question to the experts is this - how much traffic do you need to be able 
to recover the key or the plaintext?

CIPE uses disposable session keys and these are discarded based on time and 
volume usage. So my question can be phrased another way - how often should 
the session key be changed to ensure a vanishingly small chance of the 
plaintext being recovered?

Now lets look at CRC32 assuming the attacker can intercept the traffic and 
modify it in transit:

A CBC message can indeed be extended or truncated and if I have understood 
the 
quoted reference correctly it may be possible to fake the CRC32 csum too.

This may be a valid criticism of SSH but it is of no importance to CIPE for 
normal data traffic. Let me explain why.

The SSH encrypted payload is simple plaintext - it is fed directly into the 
application. If you type "echo ABC" on the client then the server passes the 
decrypted payload "echo ABC" to the shell for execution. If the attacker has 
changed this "rm -rf /" this will be passed faithfully to the shell with 
horrible results.

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.

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.

Conclusion:

The use of CRC32 in CIPE does not represent a practical security risk in the 
real world. If anyone thinks otherwise please send me the exploit.

I stand by my point that program complexity and the associated bugs - 
especially in closed source products - are the major real threat.

Best regards to you all

Allan