lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 9 Oct 2013 18:15:49 +0200
From:	Antonio Quartulli <antonio@...hcoding.com>
To:	David Laight <David.Laight@...LAB.COM>
Cc:	davem@...emloft.net, netdev@...r.kernel.org,
	b.a.t.m.a.n@...ts.open-mesh.org,
	Antonio Quartulli <ordex@...istici.org>,
	Marek Lindner <lindner_marek@...oo.de>
Subject: Re: [PATCH 10/16] batman-adv: use CRC32C instead of CRC16 in TT code

On Wed, Oct 09, 2013 at 06:10:28PM +0200, Antonio Quartulli wrote:
> On Wed, Oct 09, 2013 at 04:49:53PM +0100, David Laight wrote:
> > All CRC are linear.
> > Because '(a + b) mod c' is the same as '((a mod c) + (b mod c)) mod c'.
> > 
> > The CRC of a buffer is the XOR of the CRCs generated for each '1' bit.
> > The CRC for each bit depends on how far it is from the end of the buffer.
> 
> In our tables we cannot make any assumption about the order of the entries: the
> node whom generated the table may store the entries in a different order from
> what we have got.
> This is why I did not implemented it as a simple CRC of the
> whole the GlobalTable/buffer but I CRC'd each MAC+VID on its own.
> 
> 
> > Presetting the CRC to all-ones generates a value that is dependent on
> > the length of the buffer - otherwise missing/extra leading zeros are
> > not detected.
> 
> 
> Assuming what I said above (that we cannot make assumptions on the order of the
> entries), what is your suggestion?

Given that CRCs are commutative, the easiest answer to this question is probably to
perform the XOR of all the entries and than computing the CRC32 once
(and when computing the CRC I should start with 0xFFFFFFFF other than 0),
right?




Regards,



-- 
Antonio Quartulli

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)

Powered by blists - more mailing lists