[Bugs] [Bug 1149943] duplicate librsync code should likely be linked removed and linked as a library
bugzilla at redhat.com
bugzilla at redhat.com
Mon Dec 15 07:00:58 UTC 2014
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
More information about the Bugs
mailing list