Re: [boost] Any interest in hashing algorithms SHA and/or FNV1a?

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

On 11/14/2013 2:28 PM, Christopher Kormanyos wrote:
> Hi Jeff,
>
>> ... all the code but the call to perform_algorithm() deal with buffering,
>> which ends up being redundant with the buffering typically provided by
>> client code.
>
>
> Thank you for this astute observation. Somehow, it never dawned on
> me that the class-internal buffering can be avoided at the cost of
> slightly extended zero-buffer and padding calculations for the final
> (non-modulus-64) block.
>
> It looks like I owe you 64 bytes of precious microcontroller SRAM.

Hmm, where to spend them...

I haven't done inventory on block sizes of all of the hash algorithms, 
but it seems to me the primary interface of the hash types should include:

- compile time block size
- a function to accumulate a block
- a function to accumulate trailing final bytes

IMO buffering should be a separate component which could be used to 
implement the layered convenience functions built upon the primary 
interface.

Then I can use boost math static_lcm to get a min require block size, 
then my composite hash would make an integral number of calls for each 
sub-hash.

Jeff