Re: Data integrity check in CIPE - Please explain me the necessityor benefit of a larger checksum.

Mark,

>(PLEASE, everyone, when replying send only to list, not to person and
list -
>I get two copies)
So what: come on, you have got a delete button. The list is sometimes very
slow: it can take hours.

>> * Existing packets: possible within the lifetime of the dynamic key (15
>> minutes IIRC, so 7 min. on average) It will be seen as duplicated packets
>> within the tunnel traffic.
>
>If this were part of a complete sequence, replaying it a few seconds later
>could be catastrophic.  Even if it were TCP, a new connection faked
>correctly could cause, for example, a database transaction to be repeated,
>or worse.  Replay is an issue - not just duplicate packets sent at the same
>time.  Coupled with the checksum issue, as one of those packets may even
>have been modified, and you're looking at a vulnerability that can be used
>by someone capable of sniffing and introducing their own packets into the
>stream.

If your database transaction application doesn't have any safeguard against
this, you shouldn't probably use CIPE: it wasn't designed for that purpose.
Somebody can do the same on your LAN.

Making the key-life shorter will make this more difficult. I already
sugessted to make it configurable for that purpose.

Replay protection (using sequence/ack numbers) has some problems when UDP
datagrams are used for transport: as outlined somewhere else (by P.G.), you
have to restart your tunnel each time a UDP datagram is lost or
duplicated...

>> * Impossible IMHO, since it is computed from the encrypted packet.
>
>Could the payload be altered to include such a CRC, and compare both the
new
>and existing checksums to determine if the packet has been altered?

In theory, yes. We could make an additional CRC-32 over the payload and
append it to the buffer before compression and subsequent encryption. And
after decryption and expansion make the check in the receiver.

I am not sure, without more research, if it's a fool-proof solution. It
could be a good solution at first sight:

* It is not a time/cpu-power consuming operation and an extra 32 bit CRC
only adds max. 4 more bytes to the payload.

* It is not computable without having the de-cryption key.

* When compression is used, its location is not predictable.

* The other (unencrypted) CRC is used for detection of datacorruption caused
by transmission errors. Only the ip/udp header can be altered unnoticed, not
the payload.

*** Please let people spend some ammunition on this idea.


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>