Re: x86 asm SHA1 (draft)

[linux@horizon.com]

> The series to revamp SHA1 is good but judging the merit of each
> is outside my expertise, so I'd appreciate help to evaluate
> these changes.  For example, I cannot choose between competing
> three implementations for ppc without having access to a variety
> of ppc machines, and even if I did, ppc is not what I normally
> use, so incentive to try picking the best one for everybody is
> relatively low on my part.

Well, I'm not sure it's worth this much trouble.  Both of my PPC
implementations are smaller and faster than the current one,
so that's a pretty easy decision.  The difference between them
is 2-3%, which is, I think, not enough to be worth the maintenance
burden of a run-time decision infrastructure.  Just pick either one
and call it a day.

> The only external interface for the set of SHA1 implementation
> alternatives to the outside world is a well established SHA_CTX
> type, and three functions SHA1_Init(), SHA1_Update() and
> SHA1_Final(), and the alternative implementations are supposed
> to be drop-in replaceable.

I'd prefer it it was an *opaque* SHA_CTX type.  Sometimes you can achieve
some useful benefits by rearranging the fields.  For example, keeping the
64-bit length field as a native-order 64-bit number when appropriate.
And sometimes it's useful to have the full 80-word W[] array, while
other implementations don't want it.

> We probably would want to collect the benchmark results from
> popular platforms, have a summary to help people to choose a
> sensible one in the toplevel INSTALL file, and include the raw
> numbers in Documentation/technical/sha1-implementations.txt.

Not that numbers are bad, but I think that until there's a real
need for more than a single good-enough version per instruction set,
this is excessive.  Does hashing even show up on a profile?