| 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