URL:
<http://savannah.gnu.org/patch/?6797>
Summary: shred option to use internal RNG
Project: GNU Core Utilities
Submitted by: schveiguy
Submitted on: Tue 31 Mar 2009 06:38:01 PM GMT
Category: None
Priority: 5 - Normal
Status: None
Privacy: Public
Assigned to: None
Originator Email:
Open/Closed: Open
Discussion Lock: Any
_______________________________________________________
Details:
Hi,
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.
Thanks
-Steve
_______________________________________________________
File Attachments:
-------------------------------------------------------
Date: Tue 31 Mar 2009 06:38:01 PM GMT Name: shred.patch Size: 3kB By:
schveiguy
<http://savannah.gnu.org/patch/download.php?file_id=17845>
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/patch/?6797>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
_______________________________________________
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
