Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I've read about how to make hard drives secure for encryption, and one of the steps is to write random bits to the drive, in order to make the encrypted data indistinguishable from the rest of the data on the hard drive.

However, when I tried using dd if=/dev/urandom of=/dev/sda in the past, the ETA was looking to be on the order of days. I saw something about using badblocks in lieu of urandom, but that didn't seem to help a whole lot. I would just like to know if there are any ways that might help me speed this up, such as options for dd or something else I may be missing, or if the speed is just a limitation of the HD.

share|improve this question
    
Change your block size to something more friendly toward hard drives. dd bs=1M for example. –  Patrick Apr 12 '13 at 16:06
    
What speed were you getting? It takes a while to write an entire 3TB (for example) HDD. Also check iostat -kx 10 to see what busy % on the drive is. –  derobert Apr 12 '13 at 17:53
2  
shred -v -n 1 /dev/overwritethis is fast. It's about the only case where shred is actually useful for something. –  frostschutz Apr 12 '13 at 19:14
    
@derobert: I can't really say for sure how fast it was, but I left for a few hours, came back, and it was around 10% complete for my 500G internal HD the first time I tried this. Thanks for the "iostat" tip btw –  mellowmaroon Apr 12 '13 at 20:47
    
@Patrick: I tried bs=4M sort of blindly, since I saw that on the guide for how to put the Arch CD on a usb. It helped slightly, but it was still pretty slow. –  mellowmaroon Apr 12 '13 at 20:49
add comment

3 Answers

up vote 3 down vote accepted

dd if=/dev/urandom of=/dev/sda, or simply cat /dev/urandom >/dev/sda, isn't the fastest way to fill a disk with random data. Linux's /dev/urandom isn't the fastest cryptographic RNG around. Is there an alternative to /dev/urandom? has some suggestions. In particular, OpenSSL contains a faster cryptographic PRNG:

openssl rand $(</proc/partitions awk '$4=="sda" {print $3*1024}') >/dev/sda

Note that in the end, whether there is an improvement or not depends on which part is the bottleneck: the CPU or the disk.

The good news is that filling the disk with random data is mostly useless. First, to dispel a common myth, wiping with zeroes is just as good on today's hardware. With 1980s hard disk technology, overwriting a hard disk with zeroes left a small residual charge which could be recovered with somewhat expensive hardware; multiple passes of overwrite with random data (the “Gutmann wipe”) were necessary. Today even a single pass of overwriting with zeroes leaves data that cannot realistically be recovered even in laboratory conditions.

When you're encrypting a partition, filling the disk with random data is not necessary for the confidentiality of the encrypted data. It is only useful if you need to make space used by encrypted data indistinguishable from unused space. Building an encrypted volume on top of a non-randomized container reveals which disk blocks have ever been used by the encrypted volume. This gives a good hint as to the maximum size of the filesystem (though as time goes by it will become a worse and worse approximation), and little more.

share|improve this answer
1  
Gutmann is a myth in its entirety, I don't think it's actually ever been done for a 1980s hard disk either. The irony is that with drives getting smarter, you actually should use random data nowadays to make sure the drive is forced to write, rather than free sector (trim) or compress data. Zeroes are only good if they're actually written. –  frostschutz Apr 12 '13 at 20:07
    
So should writing with /dev/zero be ok then? It sounds like that is the case from what you're saying, including this link I found (wiki.archlinux.org/index.php/Securely_wipe_disk#Unrandom_data) –  mellowmaroon Apr 13 '13 at 0:55
1  
@mellowmaroon Yes, cat /dev/zero is almost always enough. It's only not enough if you want to hide how much space is free on the encrypted volume. –  Gilles Apr 13 '13 at 9:02
    
I guess what I'm really wondering is how much of a risk I am at by allowing the amount of free space to be visible. Sorry to keep on asking. –  mellowmaroon Apr 14 '13 at 5:52
1  
@mellowmaroon It's pretty much useless. An eavesdropper will know that you have at most X MB of data (and possibly a lot less, because formerly-used-but-now-free space is indistinguishable from used space), so what? Also the location of the free space might reveal the filesystem type (superblock copies); that's rarely a concern (it's typically exposed in the cleartext /etc/fstab, unless you've encrypted the root partition, and even then there aren't such a large number of plausible options). –  Gilles Apr 14 '13 at 8:56
show 2 more comments

Completing Marco's answer, what you need is faster random number generator.

You use a simple program that echos random numbers from a good library like boost::random and use that one in dd.

If you choose boost, you can use this example, changing the experiment function to your needs.

share|improve this answer
    
How much faster is the boost solution on your system? A quick non-scientific benchmark on my machine yields exactly the same speed as /dev/urandom. –  Marco Apr 12 '13 at 17:10
    
boost::random doesn't offer a crypto RNG, does it? If you're going to use a non-crypto RNG, you might as well use zeroes: at least you won't have an illusion of security. –  Gilles Apr 12 '13 at 18:37
    
I can't be specific about how much faster boost::random generators are, the only way to know for sure is measure their fastest algorithm against /dev/urandom –  RSFalcon7 Apr 12 '13 at 21:48
add comment

The bottleneck if neither the block size nor the hard drive, but the slow generation of pseudo-random numbers. /dev/urandom is by magnitudes faster compared to /dev/random since it's not blocking on a low entropy pool.

You can confirm this by measuring the raw output of your pseudo-random numbers:

pv /dev/urandom >/dev/null

This rate will be much slower than the write rate of your hard drive. A correct solution totally depends on your required level of security. If you require high security either use a fast hardware random generator or accept the slow speed. If your security needs are not that high, you could capture a few dozen MiB of data and write that string repeatedly to the drive. Or maybe even writing zeros from /dev/zero is an option.

Summary

/dev/random - secure, very slow
/dev/urandom - less secure¹, slow
hardware RNG - secure, fast, very expensive
(/dev/zero - not random at all, very fast)

¹According to Is a rand from /dev/urandom secure for a login key? /dev/urandom is as secure as /dev/random. Thanks to Gilles for pointing this out.

share|improve this answer
    
He's already using urandom. –  Patrick Apr 12 '13 at 17:24
    
Indeed. My point is that even urandom is too slow for his needs that's why he needs a different solution than urandom. –  Marco Apr 12 '13 at 17:27
    
    
@Gilles Thanks for the link. The man page clearly states: …As a result, if there is not sufficient entropy in the entropy pool, the returned values are theoretically vulnerable to a cryptographic attack… That's why I classified it as less secure. –  Marco Apr 12 '13 at 19:09
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.