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

["Theodore Ts'o" <tytso@mit.edu>]

On Fri, Aug 15, 2003 at 06:55:01PM -0500, Matt Mackall wrote:
> I posted a proof of concept patch for discussion on $SUBJECT. In that
> patch, I removed the folding for the purposes of having a reasonable
> comparison between cryptoapi and native. Cryptoapi does FIPS-180-1 and
> thus does twice as much hashing on 512 bits. 

It would be nice if there was a Crypto API algorithm variant which
didn't do the FIPS-180-1 padding, for those applications (like
/dev/random) that don't need it.

> Removing the folding was a convenient and obvious way of addressing
> it for the purposes of discussing $SUBECT until a good way to work
> around the extra padding was found. I've already indicated my
> willingness to accept your
> SHA-may-be-backdoored-and-somehow-leverageable argument, so can we
> kindly discuss $SUBJECT instead of this trivia?

Multiple arguments were made for dropping the folding, not just as a
"temporary measure".  You were the one that made the excuse of "cat
/dev/urandom > /dev/hda1", not me...

> As for "screwing with /dev/random", it's got rather more serious and
> longstanding problems than speed that I've been addressing. For
> instance, I'm pretty sure there was never a time when entropy
> accounting wasn't racy let alone wrong, SMP or no (fixed in -mm, thank
> you). Nor has there ever been a time when change_poolsize() wasn't an
> oops waiting to happen (patch queued for resend).

Agreed, fixing the locking is much more important than CryptoAPI
changes.  Can you send me a pointer to your latest locking patches?
I'd like to look them over.  Thanks!!

							- Ted