mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: jw schultz <jw@pegasys.ws>
To: linux-kernel@vger.kernel.org
Subject: Re: [RFC] frandom - fast random generator module
Date: Thu, 16 Oct 2003 16:35:33 -0700	[thread overview]
Message-ID: <20031016233533.GD29279@pegasys.ws> (raw)
In-Reply-To: <3F8F23BE.7020703@users.sf.net>

On Fri, Oct 17, 2003 at 01:03:26AM +0200, Eli Billauer wrote:
> Matt Mackall wrote:
> 
> >On Thu, Oct 16, 2003 at 07:29:05AM -0400, Jeff Garzik wrote:
> > 
> >
> >>So, given that trend and also given the existing /dev/[u]random, I 
> >>disagree completely:  /dev/frandom is the perfect example of something 
> >>that should _not_ be in the kernel.  If you want /dev/urandom faster, 
> >>then solve _that_ problem.  Don't try to solve a /dev/urandom problem by 
> >>creating something totally new.
> >>   
> >>
> >
> >I have some performance fixes for /dev/urandom, but there's a fair
> >amount of other cleanup that has to go in first.
> >
> ... and this reminded me that I originally wanted to patch random.c, and 
> change the algorithm to the faster one. To my best understanding, there 
> would be no degradation in random quality, assuming I would do it 
> correctly (and not being hung for the nerve to do it). But that's the 
> problem: What if I got something wrong?
> 
> If a hardware device driver is buggy, you usually know about it sooner 
> or later. If an RNG has a rare bug, or an architecture-dependent flaw, 
> it's much harder to notice. If the RNG starts to repeat itself, you 
> won't know about it, unless you happened to test exactly that data. The 
> algorithm may be perfect, but a silly bug can blow it all.
> 
> So personally, I wouldn't touch the urandom code, not even the smallest 
> fix. Instead, I decided to write another RNG, which doesn't interfere 
> with the existing one. The only way to be confident about it, is to give 
> it mileage. And that means making it available for broad use.
> 
> Which is why I originally offered frandom as a supplement, not an 
> alternative.

Sounds like a case for having a config choice for which
urandom code to build in.

-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw@pegasys.ws

		Remember Cernan and Schmitt

  parent reply	other threads:[~2003-10-16 23:35 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-16  8:22 Eli Billauer
2003-10-16  8:36 ` Nick Piggin
2003-10-16 10:20   ` Eli Billauer
2003-10-16 10:48     ` Nick Piggin
2003-10-16 11:29     ` Jeff Garzik
2003-10-16 12:27       ` Eli Billauer
2003-10-16 15:10         ` Jeff Garzik
2003-10-16 16:20       ` Andreas Dilger
2003-10-16 16:31         ` Jeff Garzik
2003-10-16 18:18           ` Andreas Dilger
2003-10-16 18:52             ` Richard B. Johnson
2003-10-16 19:31             ` Matt Mackall
2003-10-16 20:40               ` Andreas Dilger
2003-10-16 21:03             ` David Wagner
2003-10-16 23:17             ` Jeff Garzik
2003-10-16 23:42               ` Andreas Dilger
2003-10-17  0:34                 ` David Wagner
2003-10-16 17:45         ` Matt Mackall
2003-10-16 18:38           ` Andreas Dilger
2003-10-16 19:08             ` Matt Mackall
2003-10-16 20:27               ` Andreas Dilger
2003-10-16 20:37                 ` Matt Mackall
2003-10-16 17:31       ` Matt Mackall
2003-10-16 23:03         ` Eli Billauer
2003-10-16 23:07           ` Jeff Garzik
2003-10-16 23:13           ` Matt Mackall
2003-10-16 23:35           ` jw schultz [this message]
2003-10-21 19:24       ` bill davidsen
2003-10-21 19:55       ` bill davidsen
2003-10-21 21:21         ` Helge Hafting
2003-10-21 22:18           ` bill davidsen
2003-10-22  1:04             ` H. Peter Anvin
2003-10-21 19:17   ` bill davidsen
2003-10-21 21:00     ` H. Peter Anvin
2003-10-21 22:08       ` bill davidsen
2003-10-22  1:06         ` H. Peter Anvin
2003-10-22  2:56           ` jw schultz
2003-10-22 16:22             ` Kent Borg
2003-10-23  2:46               ` Dale Farnsworth
2003-10-23  3:22               ` Sandy Harris
2003-10-23 14:15                 ` Kent Borg
2003-10-24 17:37                 ` bill davidsen
2003-10-24 17:54                   ` Theodore Ts'o
2003-10-24 20:59                   ` David Wagner
2003-10-24 21:33                     ` jw schultz
2003-10-22  3:49           ` Sandy Harris
2003-10-16 10:45 ` Ingo Oeser
2003-10-21 19:30   ` bill davidsen
     [not found] <HbGf.8rL.1@gated-at.bofh.it>
     [not found] ` <HbQ5.ep.27@gated-at.bofh.it>
     [not found]   ` <Hdyv.2Vd.13@gated-at.bofh.it>
     [not found]     ` <HeE6.4Cc.1@gated-at.bofh.it>
     [not found]       ` <HjaT.3nN.7@gated-at.bofh.it>
     [not found]         ` <Hjkw.3Al.11@gated-at.bofh.it>
2003-10-16 17:46           ` David Mosberger-Tang
2003-10-16 19:28             ` Eli Billauer
2003-10-16 20:42               ` Andreas Dilger
2003-10-21 19:46                 ` bill davidsen
2003-10-16 21:30               ` Matt Mackall

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20031016233533.GD29279@pegasys.ws \
    --to=jw@pegasys.ws \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome