Boost logo

Boost :

Subject: Re: [boost] Any interest in hashing algorithms SHA and/or FNV1a?
From: foster brereton (fosterb+boost_at_[hidden])
Date: 2013-11-13 12:21:40


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?

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

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

-foster


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