Re: [patch #6797] shred option to use internal RNG

[Steve Schveighoffer]

> From: Jim Meyering

> Steven Schveighoffer wrote:
> >  
> > Our company is looking at using GNU shred to wipe customer data from RMA'd
> > drives in our systems.
> >
> > One thing we have noticed is that shred runs about 90% slower if 
> > /dev/urandom
> > exists versus when it does not.  Researching this, it seems this is because
> > gl/lib/randread.c will use an internal RNG when null is passed into
> > randread_new, and /dev/urandom cannot be opened.
> 
> Someone asked the same question not long ago.
> here's the thread:
> 
>   http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/15581
> 
> Quick answer:
> 
>   How about
> 
>     --random-source=FILE

Then I have to make a random-data file that is as big as my hard drive, which 
means I would have to write it to the hard drive first.  This would not be 
possible with a single drive, and in the case of 2 drives, it would be 
redundant since I would already have to make a utility that would write random 
data to the drive (or to stdout).  Why use shred at all?

> 
>   where FILE contains a bunch of random data,
>   like a chunk from the middle of a well-compressed tarball?
>   Or even this:
> 
>     --random-source=/dev/zero

Unlike that discussion cited, I want the random data pass.  I don't want to 
disable it.  This solution doesn't work for me.

The whole point of the patch is -- there is a perfectly usable random source 
inside shred, but it's only accessible if I remove a possibly critical 
component of my OS, /dev/urandom.  The patch just makes that behavior forcible 
without removing /dev/urandom.  I'm not trying to add any special behavior 
here, you can already get the behavior (by removing /dev/urandom).  The patch 
just makes it more practical to access the internal RNG.

-Steve