[lkml]   [2003]   [Aug]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC][PATCH] Make cryptoapi non-optional?
On Fri, Aug 15, 2003 at 06:12:11PM -0400, Theodore Ts'o wrote:

> However, if people insist on doing silly things like "cat
> /dev/urandom > /dev/hda", and worse yet, screwing with the
> /dev/random and /dev/urandom with the excuse that speed is of
> importance, then perhaps following OpenBSD and implementing
> /dev/frandom is a better choice.


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. 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?

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).

And frankly, given that my local version of /dev/urandom does 18MB/s
without starving /dev/random, I see no reason to reinvent strong PRNGs
in userspace for most applications.

Matt Mackall : : of or relating to the moon
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

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