[Bugs] [Bug 1149943] duplicate librsync code should likely be linked removed and linked as a library

[bugzilla at redhat.com]

https://bugzilla.redhat.com/show_bug.cgi?id=1149943



--- Comment #12 from Wade Mealing <wmealing at redhat.com> ---
The original intention was to move the checksum creation problem to librsync in
an attempt to avoid a known collision problem apparent in the original rsync
code.

So, I did a little more research and come up with some news about the adler32
algorithm.

So while adler32 doesn't include the problematic issue that I was avoiding with
the md5 code, it does however have its share of new problems, specifically on
small data sets. (See  http://www.zlib.net/maxino06_fletcher-adler.pdf)

I know in this particular instance, the code is checking for bit-level
corruption and not forgery however the adler32 has similar issues to the
MD5/CRC-32 implementation it replaced for data up to a few hundred bytes
because the checksums for these messages have a poor coverage of the 32
available bits. (See http://en.wikipedia.org/wiki/Adler-32) 

I think we should aim to move to sha256.  The instructions show that sha256 on
newer hardware will have significantly better results ( See
http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/haswell-cryptographic-performance-paper.pdf
) and its pretty hard to beat a 2.67 cycle hash check for a block.  I realise
not everyone has a haswell processor and intel has published the specs for a
fast SHA-256 implementation (see
http://www.intel.com/content/www/us/en/intelligent-systems/intel-technology/sha-256-implementations-paper.html
) 

Can we implement sha256 in this manner here ?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=pedEcLqMx9&a=cc_unsubscribe