Home / server / Questions / 6440
Accepted
cgp
Asked: 2009-05-09 11:22:03 +0800 CST

Is there an alternative to /dev/urandom?

  • 772

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.

linux security

15 Answers

  1. 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.

    • 24
  2. Best Answer

    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.

    • 12

  3. 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.

    • 7

  4. 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

    • 5

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

    • 5

  6. If you want to erase a huge block device then I've found it more robust to use dd and the device mapper instead of output redirection of random data. The following will map /dev/sdb to /dev/mapper/deviceToBeErased en- and decrypting transparantly in between. To fill up the device on the encrypted end, zeros are copied to the plain text side of the mapper (/dev/mapper/deviceToBeErased). 

    cryptsetup --cipher aes-xts-plain64 --key-file /dev/random --keyfile-size 32 create deviceToBeErased /dev/sdb
dd if=/dev/zero of=/dev/mapper/deviceToBeErased bs=1M

    The encrypted data on /dev/sdb is guaranteed to be indistinguishable from random data if there is no serious weakness in AES. The key used is grabbed from /dev/random (don't worry - it uses only 32 bytes).

    • 5

  7. check frandom

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

    according to my test it is fastest

    • 4

  8. 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.

    • 2

  9. /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

    • 2

  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.

    • 2