Re: ANNOUNCE: SHA-224 in Digest::SHA

From: Mark Shelor (mshelor_at_comcast.removeme.net)
Date: 12/29/03 

Date: Mon, 29 Dec 2003 13:05:10 -0700

danco@ns2.pebble.org wrote:

> However rude, abrupt, immodest and imature Tom _may_ be from time to time
> (or all the time), IMHO he is also correct in this particular instance.

To each his own, of course. But the example chosen to carp on is a bit
inconsequential.

The "sha_big_endian" quantity is in fact a constant -- not a runtime
variable -- so when the compiler encounters the "if/else" construct,
it's actually able to optimize it away. This technique enables software
to be much more readable and maintainable by avoiding #ifdef's in the
main code. I would have named it "SHA_BIG_ENDIAN", but if I'd done
that, I wouldn't have been able to have irritated Tom :)

Regarding runtime heap operations ... I assume he's referring to the
fact that "shaopen()" and "hmacopen()" make calls to malloc when
creating a handle. Well, this is exactly the way the ANSI C standard
"fopen()" does it when operating on a FILE handle. In fact, the
"sha...()" and "hmac...()" calls were modeled on the ANSI "fopen()" and
"fwrite()" interface style to promote usability.

On a more practical note, the C implementation underneath the
Digest::SHA module is quite portable, and appears to be some of the
fastest code out there (compared to, e.g., cipher/sha1.c in GNU PG).
Also, it has the distinction of handling bitstring inputs (as allowed by
the NIST SHA standard), whereas almost every other implementation is
restricted to byte inputs. Such features are quite useful for
cryptanalysis.

I don't mind responding to critiques that have actual substance, but
mere expressions of opinion such as yours don't contribute very much,
and reflect a certain gratuitous laziness. If you can point to any real
shortcomings, or examples where someone has done it better in some
demonstrable, measureable way, then please feel free to speak up.

Regards, Mark