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

To: 'CIPE-list' <cipe-l,AT,inka,DOT,de>
Subject: RE: Data integrity check in CIPE - Please explain me thenecessityor benefit of a larger checksum.
From: "Eric M. Hopper" <hopper,AT,omnifarious,DOT,org>
Date: Mon, 29 Sep 2003 11:43:27 -0500
In-reply-to: <000101c38690$9cf7e450$d100010a@lyta>
Organization: Omnifarious Software
References: <000101c38690$9cf7e450$d100010a@lyta>

On Mon, 2003-09-29 at 08:50, Mark Smith wrote:
> If we attempt to protect against modified packets then the replay would then
> only be able to send a real packet, which (with appropriate detection) we
> should then be able to drop and handle.  A simple idea that takes a little
> bit of memory is to keep track of the packets we _haven't_ seen and time
> them out after a short interval, perhaps configurable with a default.
> For example, packets may arrive in this order...
> 1     accept as initial
> 3     record that we've missed 2, expect 4 or higher
> 5     record that we've missed 4, expect 6 or higher
> 4     accept and remove record of 4
> 4     drop as we only expect 6 or higher now
> 6     accept
> then at some point remove the record of 2 as it's been too long for it to
> arrive.
> With a working stream, this queue would keep itself to a minimum unless
> there is extreme packet loss, and even then the records would time out.
> This is more a packet issue than a cryptography one, but I'm hoping it'll be
> workable.  However, it needs someone else to understand it and maybe pick
> holes in it, so please feel free...

IPSEC has a solution to this problem that we may be able to borrow. 
Since IPSEC sends IP packets, it has the same problem, and I remember
thinking the solution elegant and clever.  So, I will find the
description of it again.

Have fun (if at all possible),
There's an excellent C/C++/Python/Unix/Linux programmer with a wide
range of other experience and system admin skills who needs work.
Namely, me. http://www.omnifarious.org/~hopper/resume.html
-- Eric Hopper <hopper,AT,omnifarious,DOT,org>

Attachment: signature.asc
Description: This is a digitally signed message part

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