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

Mark,

>Second, has anyone thought about the just as serious problem of message
>replay?  Message deletion for UDP means nothing to me as UDP can drop a
>packet just as easily on it's own.  Replay either of existing or modified
>packets provides another security hole.  I believe any change should
attempt
>to address this as well since even I could figure out how to exploit it.
* 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.
* Modified packets: HMAC (encrypting the checksum) will make that
impossible.

>As for CRC itself - can I ask, is the checksum calculated pre- or post-
>encryption?
* POST
>Could a copy of the checksum be included in the payload for
>comparison to ensure it hasn't been altered, but without compromising the
>encryption key?  I'd imagine that if the checksum was then compressed it
>would be 'harder' to compromise.  Would this be enough, perhaps for both
>vulnerabilities?
* Impossible IMHO, since it is computed from the encrypted packet.
* However:
** ip-packets contain a CRC-16 over the header only,
** tcp contains a CRC-16 over header and data + sequence / ack numbers,
** udp datagrams contain a CRC-16 over data and header.

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>