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 17:45:11

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

On 04/05/2010 12:44 PM, Scott McMurray wrote:

>> 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.
> 
> Why do you prefer that method?  Since get_digest adds padding, calling
> get_digest or process_byte again without a reset doesn't provide
> anything useful.  Also, the reset is just a few copies, completely
> negligible compared to the cost of the one or two block compression,
> so omitting it saves nothing.

Agreed, on all points. But unless the function is named such that it's
very obvious that it resets the object as well as returns the hash
value, people will be surprised that it reset itself when they didn't
tell it to.

>> 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.
> 
> They should definitely use the same interface.  As mentioned, they
> need a Concept to which generic code can be written.  I mostly just
> had them separate because the precedent is Boost.CRC, not
> Boost.ErrorDetectingCode.

Off the top of my head, I think Boost.CRC supports my argument, since I
believe it includes Adler codes. They're a form of CRC, but aren't what
most programmers think of when you say CRC.

>> 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.
> 
> More formats would be great, and is part of the reason for separate
> libraries, since I'm certain that others will want to add more
> formats, and shouldn't have to go through the first person to propose
> some, as Boost guidelines prefer for additions to existing libraries.

I don't know the details, but there may be precedent for an umbrella
library name with different but related parts by different authors:
Boost.Math.

> Speaking of byte-oriented, one great bit about templating is that the
> preprocessing stage can be written generically and fed with
> different-size types (so bit, byte, and different words all work) and
> to different backends, so SHA-1/256/384/512 all use the same
> preprocessor.  It's still efficient, too -- it works out the same or a
> few percent faster than the version Andy found for
> boost/uuid/sha1.hpp.
> 
> Adding a few more algorithms will be an important test of this
> genericity, though.

Just let me know if you'd like to see the code... and don't laugh too
hard when you do, I was young(er) and foolish when I wrote it. :-)
- -- 
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/

iEYEARECAAYFAku6WeMACgkQp9x9jeZ9/wSd0gCfSn/pvVjHfuCws1dtAWErhPCS
wGcAn2l89EdKajIUiaE6s8saKlTXtO04
=Pc0g
-----END PGP SIGNATURE-----