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

[Jamie Lokier]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/