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

To: "Mark Smith" <mark.smith,AT,avcosystems,DOT,co,DOT,uk>
Subject: Re: Data integrity check in CIPE - Please explain me the necessityor benefit of a larger checksum.
From: "Hans Steegers" <hsx,AT,dds,DOT,nl>
Date: Mon, 29 Sep 2003 12:34:55 +0200
Cc: "CIPE-list" <cipe-l,AT,inka,DOT,de>
Reply-to: "Hans Steegers" <steegers,AT,steegers,DOT,nl>

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


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