Re: [RFC][PATCH] Make cryptoapi non-optional?

Jamie Lokier
2003-08-09T17:14:44Z

Matt Mackall wrote:
> This code is already at about 125% of baseline throughput, and can
> probably reach 250% with some tweaking of cryptoapi's redundant
> padding (in case anyone else cares about being able to get 120Mb/s
> of cryptographically strong random data).

Why would the cryptoapi version be faster, I wondered? So I had a look.
No conclusions, just observations.

- random.c defines a constant, SHA_CODE_SIZE. This selects between
4 implementations, from smaller to (presumably) faster by
progressively unrolling more and more.

This is set to SHA_CODE_SIZE == 0, for smallest code.

In crypto/sha1.c, the code is roughly equivalent to SHA_CODE_SIZE == 3,
random.c's _largest_ implementation.

So you seem to be replacing a small version with a large version,
albeit faster.

- One of the optimisations in crypto/sha1.c is:

/* blk0() and blk() perform the initial expand. */
/* I got the idea of expanding during the round function from SSLeay */

Yet, random.c has the opposite:

/*
* Do the preliminary expansion of 16 to 80 words. Doing it
* out-of-line line this is faster than doing it in-line on
* register-starved machines like the x86, and not really any
* slower on real processors.
*/

I wonder if the random.c method is faster on x86?

- sha1_transform() in crypto/sha1.c ends with this misleading
comment. Was the author trying to prevent data leakage? If so,
he failed:

/* Wipe variables */
a = b = c = d = e = 0;
memset (block32, 0x00, sizeof block32);

The second line will definitely be optimised away. The third
could be, although GCC doesn't.

Enjoy,
-- Jamie