[GNU Crypto] Faster hashes (SHA1, Tiger)

[Philippe Verdy]

I know that you have designed your GNU Crypto API for Java on your own
"IMessageDigestSPI" interface instead of the classical "MessageDigestSPI" (you
wanted to have a supplementary function to self-test the hashes, but these
self-tests are really not enough to detect possible JVM bugs such as the one in
the latests Java 1.4.1 which occurs only on MacOSX 10.2, but not on 10.3).

Well I have started to reimplement some hashes for performance, and my own
version really outperforms the Sun/Apple JCE providers, Cryptix, jPython, and
GNU Crypto...

An example is with SHA1 (where you can compare it with the Sun/Apple JCE
providers).
I have made it for public use in the Bitzi open-source project, or in LimeWire,
and donated this code to Sun and Apple as well for their JCE.

Look into this source and the test module:

http://groups.yahoo.com/group/the_gdf/files/Proposals/Working%20Proposals/HUGE/com.bitzi.util/SHA1.java

http://groups.yahoo.com/group/the_gdf/files/Proposals/Working%20Proposals/HUGE/com.bitzi.util/SHA1Test.java


Same thing with the "Tiger" digest:

http://groups.yahoo.com/group/the_gdf/files/Proposals/Working%20Proposals/HUGE/com.bitzi.util/Tiger.java

http://groups.yahoo.com/group/the_gdf/files/Proposals/Working%20Proposals/HUGE/com.bitzi.util/TigerTest.java

You'll note how much this code is optimized to reduce all avoid as much as
possible the accesses to class members, or to array indices (due to the cost of
array bounds checking). It also avoids almost all internal copy into work
buffers, and maximizes the reuse of local variables within subexpressions.

If you compare my version of SHA1 with the Sun JCE one, you'll see that my
implementation is more than TWICE faster, with no extra VM allocations to
process input buffers. The compiled code is also smaller.