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
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
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
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.
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