Re: Re: Adler-32 Checksum

Thomas Dreibholz <[email protected]> Tue, 28 Jun 2005 15:25:40 +0200
Newsgroups gmane.ietf.rserpool
Organization University of Duisburg-Essen, Institute for Experimental Mathematics
Message-ID <[email protected]>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 28 June 2005 14:56, Michael Tuexen wrote:
> > For the handlespace audit, it is necessary to have a checksum
> > function f which
> > provides the property that when a PE entry b is deleted from the
> > set of PE
> > entries a,b,c, then the checksum f(ac) has to be computable by f
> > (abc) - f(b)
> > without re-computing f(a) or f(c). "-" denotes an appropriate
> > subtraction
> > operation. Furthermore, it must be possible to add an element b to
> > the set of
> > PE entries a,c and compute the checksum f(abc) = f(a) + f(b) + f(c)
> > without
> > having to re-computing f(a) or f(c) ("+" denotes and appropriate
> > concatencation function).
>
> That is one question: Do we want such a function? Adler32 and CRC do not
> have the property. The Internet checksum has. I would prefer the
> Internet
> checksum to XOR.
> But the question remains: Do we need the function which with 'an update
> possibility' or can we just recompute the stuff?

It is necessary to have an update possibility. Otherwise, each time a small 
change is made to the handlespace, a complete re-calculation of the 
handlespace checksum is necessary. Consider a handlespace with thousands of 
PEs this would cause a significant effort. An evil PE could exploit this 
behaviour by registering and deregistering at a high frequency and cause a 
DoS.


> The problem I see is that by computing we really compare stuff. But
> just doing
> incremental updates we might report something we really do not have
> anymore
> in the cache (due to sume bugs, for example).

If PEs are removed, the implementation must update its checksum. If the 
checksum is not updated, the implementation is broken and should be fixed. 
IMHO, it should not be complicated to ensure that after an entry has been 
added or removed the checksum is updated. By using an inefficient checksum 
algorithm, a significant performance impact is imposed on every correct 
implementation. And this would be a very bad thing.


I think, the Internet checksum algorithm (may be with keeping the full 32 bits 
instead of truncating to 16 bits) should already be sufficient for the audit 
purpose. Using this checksum algorithm, we also get order-invariancy and do 
not need to force a specific ordering of the handlespace within a management 
component. It is furthermore very simple and fast (only + and ~ operations 
are needed, no *, / or %).


Best regards
- -- 
=======================================================================
 Dipl.-Inform. Thomas Dreibholz

 University of Essen,                            Room ES210
 Inst. for Experimental Mathematics              Ellernstraße 29
 Computer Networking Technology Group            D-45326 Essen/Germany
- -----------------------------------------------------------------------
 E-Mail:     [email protected]
 Homepage:   http://www.exp-math.uni-essen.de/~dreibh
=======================================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFCwU/Y32BbsHYPLWURAvVkAKCzmbkwGqSWUOhnO1LkTYMqbPE3iQCfZ/Na
vhWiJ2Z2x1+ntoKqqkMSJjc=
=N0tj
-----END PGP SIGNATURE-----