GNU 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: |
Pádraig Brady <pixelbeat> |
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?
|
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> |
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
|
Jim Meyering <meyering> |
Tue 31 Mar 2009 06:38:01 PM UTC, original submission:
Hi,
|
Steven Schveighoffer <schveiguy> |
Depends on the following items: None found
Items that depend on this one: None found
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/Closed | Open | Closed | |
2010-07-14 | pixelbeat | Status | In Progress | Done | |
2009-04-01 | meyering | Status | None | In Progress | |
2009-03-31 | schveiguy | Attached File | - | Added shred.patch, #17845 |
Powered by Savane 3.13-3230.
Corresponding source code
Since coreutils v7.1 shred uses the internal PRNG by default:
http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=af5723c7