Data integrity check in CIPE - Please explain me the necessity or benefit of a larger checksum.

To all!

Can somebody PLEASE explain to me the benefit of a larger checksum:

1. Below is the packet layout of a CIPE protocol-3 UDP datagram:
*--------+-------+----+---------------------+------+--------+--------+
| ip-hdr | udp-h | IV | encrypted ip packet | padd | P-byte | crc-32 |
| 20 B   | 8B    | 8B |<-- variable size -->| 1-7 B| 1 Byte | 4 Bytes|
*--------+-------+----+---------------------+------+--------+--------+
|<----------- the crc is computed over this part ---------->|
The CRC-32 is computed over the whole datagram minus (of course) the 4 CRC
bytes.

2. Even if the hash is 512 bytes long, it is just as easy to generate a new
hash over the altered datagram as it is for a 4-byte checksum. (It only
takes a whole lot more time.) The receiver doesn't know what CRC value to
expect, except that it must match its own computation for the received
datagram, just for detection of packet corruption (e.g. caused by
transmission problems), so it is not wasting time on decrypting and
expanding corrupted packets.

3. If I want to successfully insert a spoofed datagram, I still need to know
the key in use. If I don't, the decryption will (a) fail or (b) create an
invalid ip-packet. If compression is used (CipeX), decompression will fail
and the datagram will be dropped...
A more complex hashing will not change anything: I change the datagram,
generate a new hash (CRC-8..64,SHA-1, whatever is required) and send it. The
receiver will accept it as a valid datagram, as long as the new hash was
computed correctly.

4. If I want to replay a certain stream of datagrams, I need insider
information on what is exchanged over the tunnel to make it work: packet
size could be used to trigger the recording of a sequence to be replayed
within the life time of the key in use (on average 7 minutes IIRC). If
compression is used, this is almost impossible because the packet size
depends in that case on the (compressability of the) packet contents.
[I think it is easier to compromise the computer, get root access and steal
the static key.. -or to steal two complete mainframes as (allegedly) the
mossad did recently in Australia :-)].

5. The information integrity vulnerability in the SSH1 protocol is IMHO
related to the RC4 encryption (and -by the way- has as pre-condition:
disabled compression) See: http://www.kb.cert.org/vuls/id/25309

** So can somebody PLEASE PLEASE PLEASE PLEASE EXPLAIN to ME why we need MD5
or SHA-1 (up to 20 bytes) if it is just as easily generated for a modified
datagram as with CRC-32 ? ? ?

What is the real benefit of such a long message digest? What does it change?
I must be missing something here..

It would be a real waste to implement a 16 or 20 byte checksum with a high
CPU load, if there is no real gain in additional security.
It would be a fake solution to a fake vulnerability, wouldn't it!?  And
could become another item on /. ...

I need to be really convinced of the benefit before investing time in such
an operation. My own investigations (so far) didn't convince me at all!.

SO, PLEASE PLEASE PLEASE PROVE ME WRONG!
WITH ARGUMENTS and WITHOUT PARROTTING FUD, PLEASE!

Such a fun!

P.S.
Almost no more virus-infected mail received.
Sunday: 4, Saterday: 8, Friday 34.
Thanks!

__________________________________________________
Hans Steegers



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