On Wed, Nov 13, 2013 at 6:43 AM, Jeff Flinn
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