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

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 <[email protected]>

-----BEGIN PGP MESSAGE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQA/eGEujtsvlOwvazYRAlruAKCbb616gJBASz0mcOMEk3CI1WOLSQCfYBD5
4xc2GANwJAQsDlLHyhv5vXI=
=EzO/
-----END PGP MESSAGE-----