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

[Jim Meyering]

hggdh wrote:

> On Wed, 01 Apr 2009 17:14:42 +0200
> Jim Meyering <address@hidden> wrote:
>
>> 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
>>
>>   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
>
> Indeed this works; nevertheless there are some potential issues:
>
> (1) the "FILE" will have to be a pipe for very large shredded files; so
> we are pretty much not really helping, since we are leaving to the user
> the task of setting it up. I can see this as an additional option, but
> I also feel that we should provide a basic, workable, one;

With a modern shell like bash or zsh, you can use process substitution
and hook up a program:

  --random-source=<(openssl rand 10000000...)

That openssl command can generate data at the rate of about 20MB/s.

Though perhaps something deeper is wrong, if shred's use of
/dev/urandom makes the whole process too slow.

> (2) --random-source=/dev/zero will bypass (1), but will defeat the idea
> of a random shredding;
> (3) finally -- and more critical, perhaps -- the new default for
> --iteractions forces *all* three (default) passes to be random.

That might deserve attention.