Boost logo

Boost :

Subject: Re: [boost] Any interest in hashing algorithms SHA and/or FNV1a?
From: Jeff Flinn (Jeffrey.Flinn_at_[hidden])
Date: 2013-11-13 12:53:15


On 11/13/2013 12:21 PM, foster brereton wrote:
> On Wed, Nov 13, 2013 at 6:43 AM, Jeff Flinn <Jeffrey.Flinn_at_[hidden]> wrote:
>> On 11/12/2013 1:52 PM, foster brereton wrote:
>>>
>
> [snip]
>
>> Have you seen:
>> https://github.com/boost-vault/Miscellaneous/blob/master/boost_crypto.zip
>> https://github.com/boost-vault/Miscellaneous/blob/master/crypto_v01.zip
>
> I have not - I'll grab them and have a look.
>
>> I'll take a look at your ASL links today. Do you have any comparisons with
>> openssl or libcryptocpp?
>
> I do not - I am assuming the specific context you're thinking of is performance?

Yes, with the bottom line being overall throughput of the data and
hashes of many files.

>> The other issue I have is that with the above mentioned api's each duplicate
>> buffering of incoming data. So in my case I've got the disk, os,
>> std::stream_buf, MD5 and SHA1 each doing buffering. Seems that these could
>> be merged and there would be benefit to interleaving disk io with processing
>> the composite hash on a 64 byte block basis. I know the number of incoming
>> full blocks and would like to call the vault's crypto_v01 process_block
>> functions for those and then call update with the remaining partial block.
>
> Both FNV and SHA implementations do no additional buffering. They do
> store internal state to manage the current digest, operating message
> block, etc. There is no duplication of user data during digest.

Cool if I can call with a single block at a time.
>
>> So, bottom line - I'm interested.
>
> Great - I know ASL has an MD5 implementation as well (also header
> only, with minimal dependencies.) I haven't looked at it in a long
> while, and am sure it could do with some cleaning up (especially given
> what's available now in C++11). If there's enough demand I can roll
> md5 into the mix, too.

Very timely! :-)

Jeff


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk