patchGNU Core Utilities - Patches: patch #6797, shred option to use internal RNG


You are not allowed to post comments on this tracker with your current authentication level.

patch #6797: shred option to use internal RNG

Submitter:  Steven Schveighoffer <schveiguy>
Submitted:  Tue 31 Mar 2009 06:38:01 PM UTC
Category:  None Priority:  5 - Normal
Status:  Done Privacy:  Public
Assigned to:  None Open/Closed:  Closed

Jump to the original submission

Wed 14 Jul 2010 03:00:10 PM UTC, comment #6: 

Since coreutils v7.1 shred uses the internal PRNG by default:;a=commitdiff;h=af5723c7

Pádraig Brady <pixelbeat>
Group administrator
Sun 05 Apr 2009 08:44:02 AM UTC, comment #5: 

IMO both /dev/urandom and /dev/random should be used as sources of data for seeding PRNGs, as opposed to being used as sources of random data directly.   My rationale for this is that even using /dev/urandom for large quantities of data will exhaust the system's entropy pool. 

James Youngman <jay>
Wed 01 Apr 2009 08:38:33 PM UTC, comment #4: 

Thanks for the suggestion, but I really don't understand the reluctance to utilize the (already implemented) internal random number generator.  It's there, it costs nothing extra to use it, it doesn't require extra programs that generate random data, nor external files.  It's even the default case when /dev/urandom does not exist.  What is the downside?

Incidentally, the hack I would choose over all the ones suggested is to chroot to remove /dev/urandom.   I'd just have to copy the disk nodes to a ghosted /dev directory.

Steven Schveighoffer <schveiguy>
Wed 01 Apr 2009 06:57:11 PM UTC, comment #3: 

The random data does not have to reside on disk.  You can use a named fifo and use another process to generate random data into the pipe.  In other words, if you can generate the data on the fly, you do not need pre-save it on disk.  Modern shells make this easy with process substitution: --random-source=<(your random generator process).  But even without that, coreutils includes the mkfifo program to create your own named fifo.

Eric Blake <ericb>
Group administrator
Wed 01 Apr 2009 05:45:33 PM UTC, comment #2: 

The solution in that discussion does not work for me.  I want the random data.  I also cannot build a random file that's as big as the hard drive, since I would need a hard drive to store it.  Furthermore, there is already a random number generator built into shred, why should I have to invent my own?

Steven Schveighoffer <schveiguy>
Wed 01 Apr 2009 03:24:28 PM UTC, comment #1: 

see discussion/solution on

you're welcome to reopen if that doesn't solve it for you.

Jim Meyering <meyering>
Group administrator
Tue 31 Mar 2009 06:38:01 PM UTC, original submission:  


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.

However, there is no way to force this behavior without removing /dev/urandom (if you pass in an invalid file name, shred exits with an error).  It is not important to us that the data isn't truly random, pseudorandom data seeded the way it is done in shred is sufficient.  However, it is important that the wiping of the drive completes in a reasonable time.  When not using /dev/urandom, a single pass on a 160G drive on a system takes roughly an hour.  When using /dev/urandom, it takes 28 hours.  Furthermore, since the CPU is now the bottleneck, wiping several drives in parallel will not take advantage of the ability to use multiple hard drive channels, the time will scale roughly linearly.  When /dev/urandom is not used, the time to add an extra drive increases by a couple minutes.  We regularly work with 750GB and 1TB drives, and we plan on doing 2 passes, so you can see how this problem will balloon out of reasonable range.

I would like to propose that an option be allowed to force usage of the internal RNG.  This can be done by passing a filename into randread that is a special filename, or by adding an argument to the randread create functions, or by adding a different create function.

I've attached a patch that will allow for this in both randread.[ch] and a special option in shred.c that forces the issue.  Note that this patch is on the released 7.2 code, not the git directory structure.  The patch specifies a blank filename is the special file that signals to use the internal RNG.  I also added the option -i (--random-internal) to shred to signify this option.

Please let me know if you guys intend on accepting this patch or something like it. if not, we will simply use it internally, otherwise, I'll download the official version when you release it.



Steven Schveighoffer <schveiguy>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #17845:  shred.patch added by schveiguy (3KiB - text/x-diff)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by pixelbeat (Posted a comment)
  • -email is unavailable- added by jay (Posted a comment)
  • -email is unavailable- added by ericb (Posted a comment)
  • -email is unavailable- added by meyering (Posted a comment)
  • -email is unavailable- added by schveiguy (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.


    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2010-07-14 pixelbeat Open/ClosedOpen Closed
    2010-07-14 pixelbeat StatusIn Progress Done
    2009-04-01 meyering StatusNone In Progress
    2009-03-31 schveiguy Attached File- Added shred.patch, #17845

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code