Is there an alternative to /dev/urandom?

Question

Is there some faster way than /dev/[u]random? Sometimes, I need to do things like

cat /dev/urandom > /dev/sdb

The random devices are "too" secure und unfortunately too slow for that. I know that there are wipe and similar tools for secure deletion, but I suppose there are also some on-board means to that in Linux.

Answer 1

If you're looking to do a "secure" erase of a hard drive (or file), you ought to look at the shred utility.

As the previous posters point out, the /dev/*random devices are meant to be used as a source of small chunks of random data.

Answer 2

In a quick test under Ubuntu 8.04 on a Thinkpad T60p with T2500 CPU, 1GB of random data from openssl rand was 3-4X faster than /dev/urandom. That is,

time cat /dev/urandom | head -c 1000000000 > /dev/null

...was around 4 minutes while...

time openssl rand 1000000000 | head -c 1000000000 > /dev/null

...was just over 1 minute.

Unsure if there's a difference in random-quality, but either is probably fine for HD-wiping.

Answer 3

Unfortunately Linux has bad implementation of urandom. You could use aes256-ctr with a random key and get several hundred megabytes of pseudo-randomness per second, if your CPU supports AES-NI (hardware acceleration). I am looking forward to urandom switching to a modern approach as well.

openssl enc -aes-256-ctr -pass pass:"$(dd if=/dev/urandom bs=128 count=1 2>/dev/null | base64)" -nosalt < /dev/zero > randomfile.bin

This puppy does 1.0 GB/s on my box (compared to 14 MB/s of /dev/urandom). It uses urandom only to create a random password and then does very fast encryption of /dev/zero using that key. This should be a cryptographically secure PRNG but I won't make guarantees.

Answer 4

If you need to securely wipe a HD there is one tool very powerful: DBAN

Answer 5

The faster your tool the less secure the result will be. Generating good randomness takes time.

Anyway, you could use something like dd if=/dev/zero of=/dev/sdb, but obviously that isn't going to be random, it will just erase much faster.

Another option might be to use this method /sbin/badblocks -c 10240 -s -w -t random -v /dev/sdb it is faster then urandom, but the badblocks PRNG is less random.

Answer 6

check frandom

http://billauer.co.il/frandom.html

according to my test it is fastest

Answer 7

I see a lot of answers saying that using random data isn't important. That's pretty much true if all you are trying to do is wipe the drive, but not so much if you are wiping it in preparation for disk encryption.

If you fill a device with non-random data then place an encrypted partition on it you might run into a problem. The portion of the drive which is storing encrypted data will stand out from the rest of the drive, because the encrypted data will look random and the rest won't. This can be used to determine information about the crypto disk that could be used in cracking it. The link below explains the theory behind how some of the more common attacks work and how to defend against them (on Linux, anyway).

Linux hard disk encryption settings

Answer 8

/dev/random uses a lot of system entropy, and so produces only a slow data stream.

/dev/urandom is less secure, and faster, but it's still geared towards smaller chunks of data - it's not meant to provide a continuous stream of high speed random numbers.

You should make a PRNG of your own design, and seed it with something from /dev/random or /dev/urandom. If you need it a bit more random, seed it periodically - every few MB (or whatever the length of your prng is). Getting 4 bytes (32 bit value) from urandom or random is fast enough that you can do this every 1k of data (reseed your prng every 1k) and get very random results, while going very, very, quickly.

-Adam

Answer 9

In practise there's probably no need to seed the whole disk from one continuously random stream.

You could create a modest sized chunk of random data and then just repeat that over and over across the disk.

Just make sure that that chunk of data is not a multiple of the disk's normal block size, to ensure that you don't end up overwriting correlated blocks of data with the exact same bit of random data. A chunk size that's a prime number in the ~1MB range should do nicely.

For additional security, just do it a few times more, using a different chunk size each time.

Answer 10

If you want to wipe a hard drive quickly, write nonrandom data to it. This is no less secure than using random data. Either way, when hooked up to a computer the original data can't be read. Overwriting Hard Drive Data: The Great Wiping Controversy shows that the original data can't be read using a microscope either.

Answer 11

Format with LUKS, and dd over the encrypted volume. Then use /dev/urandom to wipe the LUKS header.

If you have hardware AES support this is a very fast solution.

Briefly:

cryptsetup luksFormat /dev/sdX
cryptsetup luksOpen /dev/sdX cryptodev
dd if=/dev/zero bs=1M of=/dev/mapper/cryptodev
cryptsetup luksClose cryptodev
# wipe the luks header.  Yes, it uses /dev/urandom but only for 2MB of data:
dd if=/dev/urandom bs=1M count=2 of=/dev/sdX

done!

See my blog: Quickly fill a disk with random bits (without /dev/urandom)

Answer 12

The 'shred' utility is easy and fast. If the SMART attributes of the drive indicate zero re-allocated sectors, 'shred' is likely secure enough.

However, if the drive has re-allocated sectors, the data on damaged sectors will not be overwritten. If the damaged locations contained sensitive data before they were re-allocated, 'shred' may not be good enough. The 'bad' sectors may be read by resetting the drive's allocation map, and (repeatedly) reading them.

The ability to reset the bad sector allocation map varies depending on manufacturer and drive model.

Answer 13

If all you want to do is overwrite the disk, then it doesn't matter what you use because anything at all will beat anything short of a forensics lab and I wouldn't trust anything short of slagging the drive to stop that level of resources.

Just use a non random source like all zeros or ones or a repeating pattern like (I think this will work)

(head -c 4096 /dev/urandom; cat /dev/sdb/) > /dev/sdb