<< | Thread Index | >> ]    [ << | Date Index | >> ]

To: Hans Steegers <steegers,AT,steegers,DOT,nl>
Subject: Re: Data integrity check in CIPE - Please explain me the necessityor benefit of a larger checksum.
From: "Eric M. Hopper" <hopper,AT,omnifarious,DOT,org>
Date: Sun, 28 Sep 2003 18:48:12 -0500
In-reply-to: <000f01c3860e$73daf760$d620a8c0@pcw_hans.hnsasd.priv>
Organization: Omnifarious Software
References: <000f01c3860e$73daf760$d620a8c0@pcw_hans.hnsasd.priv>

On Sun, 2003-09-28 at 17:18, Hans Steegers wrote:
> 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.

If you simply use a 512 bit hash in the manner you describe, you will
have exactly the results you predict.

HMAC hashes a key along with the data.  Someone who doesn't know the
HMAC key can't verify the hash.  HMAC is what should be used here.  The
HMAC key must be a seperate key from the encryption key.

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

No, you are incorrect.  Within the time window a key is valid, I can
replay a packet that was already sent with slight modifications.

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

No, a keyed hash like HMAC will prevent this from being feasible.

> 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 :-)].

They initial key exchange packets that use the static key are very
vulnerable.  An attacker can force a situation in which this exchange
must be carried out.

Additionally, many Internet protocols are very predictable.  It is
relatively simple to guess what packet is happening when simply by
knowing the protocol.

> 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

No, CBC-DES3 in SSH1 is also vulnerable.  In fact, every encryption
algorithm is vulnerable.  You need cryptographically secure data
integrity checking to ensure data integrity.  No block cipher algorithm
and mode that's free of patents provides both.

You are correct in your assertion that compression makes things harder. 
The problem is, how much harder?  Can you give a hard quantifiable
number on that?  Can you state with any certainty that a protocol
requires x amount of computation to break without compression, and x + y
with?

Proper data integrity checking fills this role nicely.  You can give
hard limits on those things.  I can tell you that the lower bound on the
chance that an attacker can successfully spoof a packet is 2**-24
(birthday attacks halve the effective number of bits) if you have 48
bits of HMAC-SHA-1 data at the end with a secure HMAC key.

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

I just did.

> 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've been studying cryptography and cryptographic protocols for the past
2-3 years.  I won't make any statements about my credentials, but I do
know for certain the Peter Gutman's arguments are valid, and that the
solution I propose will significantly improve things.

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 <hopper,AT,omnifarious,DOT,org>

Attachment: signature.asc
Description: This is a digitally signed message part


<< | Thread Index | >> ]    [ << | Date Index | >> ]