lkml.org 
[lkml]   [2003]   [Aug]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC][PATCH] Make cryptoapi non-optional?
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:47    [W:0.158 / U:3.948 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site