Re: [boost] Message Hashing Interface (SHA-1/256/384/512, MD4/5)

Subject: Re: [boost] Message Hashing Interface (SHA-1/256/384/512, MD4/5)
From: Chad Nelson (chad.thecomfychair_at_[hidden])
Date: 2010-04-05 10:26:22

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/04/2010 12:09 PM, Scott McMurray wrote:

> I wrote up some SHA message hashers recently, which came out rather
> nicely using templates to handle the commonalities between
> SHA-1/256/384/512.

I realize I'm still new here, but having written a large library of
hashing functions myself several years ago (purely for fun, never
used... I was thinking of proposing it for Boost inclusion after XInt),
I feel that I have a little experience to contribute.

> The one issue that came up is how to handle retrieving the hash from
> the accumulator. [...]
> 
> Here are a couple of options:
> 
> 1) The hash() function is non-const, and it appends the passing and
> length, calculates the hash, and resets the accumulator to be ready
> for the next message. This is perhaps the most efficient interface.
> [...]
>
> I think I like (1) best, because it allows the user to copy it and get
> (2) if they'd rather, and doesn't have the potential call sequencing
> problem of (3).
> 
> Any opinions, suggestions, alternatives, or comments?

I agree with your opinion, with a slight variation: don't reset the
accumulator until the user explicitly requests it. It seems
counterintuitive, though I'm sure it could be made obvious with the
proper function naming.

> P.S.  Yes, the point here is to create Boost.MD and Boost.SHA
> libraries. [...]

Is there a particular reason to separate the two (conceptually)? A
Boost.CryptographicHash library, covering those and several other
commonly used ones, seems more appealing. They would, of course, still
be *logically* separate, they'd just be under the same umbrella name,
and share the same interface.

I'll contribute code for several more formats (MD2, RIPEMD
128/160/256/320, Tiger 128/160/192, Tiger2 128/160/192, and Whirlpool,
all byte-oriented only), if you're interested. They probably need some
work (they were written several years ago), but the core code is sound.

I'm pretty sure none of them are patent-encumbered, but of course I'd
make certain.
- -- 
Chad Nelson
Oak Circle Software, Inc.
*
*
*
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAku58wkACgkQp9x9jeZ9/wT/BACcCF6oLl4NdoDfIGYT3//V9bof
5egAoJPJaZxIGBggCJlioBYLEdQeJF+R
=7am8
-----END PGP SIGNATURE-----