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: Scott McMurray (me22.ca+boost_at_[hidden])
Date: 2010-04-05 12:44:38

On 5 April 2010 10:26, Chad Nelson <chad.thecomfychair_at_[hidden]> 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.

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

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

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.