Re: Data integrity check in CIPE - Please explain me the necessityor benefit of a larger checksum.|
"Hans Steegers" <hsx,AT,dds,DOT,nl>|
Mon, 29 Sep 2003 15:07:38 +0200|
"Hans Steegers" <steegers,AT,steegers,DOT,nl>|
>(PLEASE, everyone, when replying send only to list, not to person and
>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
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
>> * Impossible IMHO, since it is computed from the encrypted packet.
>Could the payload be altered to include such a CRC, and compare both the
>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
*** Please let people spend some ammunition on this idea.