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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 9 Oct 2013 16:49:53 +0100
From:	"David Laight" <David.Laight@...LAB.COM>
To:	"Antonio Quartulli" <>
Cc:	<>, <>,
	"Antonio Quartulli" <>,
	"Marek Lindner" <>
Subject: RE: [PATCH 10/16] batman-adv: use CRC32C instead of CRC16 in TT code

> > Are you really generating CRC32 of a pile of ethernet MAC addresses
> > and the XORing the CRC together?
> > That gives the same answer as XORing together the MAC addresses and
> > then doing a CRC of the final value.
> I was not sure about this since the CRC32 is not a linear operation. However
> this routine is not on the fast path, so we can also live with this order.

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.
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.


Powered by blists - more mailing lists