Performance tuning for the XO

[NoiseEHC]

There is a crypto++ library:

hash functions SHA-1 <http://www.cryptolounge.org/wiki/SHA-1>, SHA-2 
<http://www.cryptolounge.org/wiki/FIPS_180-2> (SHA-224, SHA-256, 
SHA-384, and SHA-512), Tiger <http://www.cryptolounge.org/wiki/Tiger>, 
WHIRLPOOL <http://www.cryptolounge.org/wiki/WHIRLPOOL>, RIPEMD-128, 
RIPEMD-256, RIPEMD-160, RIPEMD-320

It has an MMX Whirlpool, and SSE2 SHA implementation.
The problem is that it is written in C++ and assembly and the MMX 
implementation could be slower than the C++ one on the Geode. see:
http://wiki.laptop.org/go/Geode

All in all, include in speed testing.

C. Scott Ananian wrote:
> On 9/22/07, Mitch Bradley <wmb at laptop.org> wrote:
>   
>> Some timing for libtomcrypt with various compilation options.  All times
>> are for hashing 1MiB of data from memory, timed under Open Firmware with
>> interrupts disabled.
>>     
> [...]
>   
>> So, with this code, the slow version does sha256 at about 4 MiB/sec, the
>> fast version does sha256 at about 5.3 MiB/sec, and rm160 goes at 9
>> MiB/sec in all cases.
>>     
>
> Hmm.  I did browse through all the SHA256 implementations I could
> find, looking at libtomcrypt, libgcrypt, and openssl in particular.
> Most of what I've seen has followed the definitions in the SHA
> standard pretty closely; unrolling the loops seems to be the only
> common "optimization".  Assuming you were starting from portable C
> code, it seems that compiler quality had the most effect, which made
> me realize that I don't actually know the appropriate machine type to
> pass the the GCC optimizer, prompting my original post.
>
> Some more SHA256 implementations I found which claim to be optimized:
>    http://www.ouah.org/ogay/sha2/
>    http://fp.gladman.plus.com/cryptography_technology/sha/index.htm
>
> I'd gladly accept a volunteer to go through and benchmark different
> implementations on XO hardware.  From my initial investigations, it
> seems like we should use RIPEMD-160 for bulk hashing of filesystem
> data.  There were some recent cryptoanalytic results against RIPEMD,
> however; I need to go off and reread them to get a sense for its
> current level of security.
>  --scott
>
>