Zeros are far more efficient and much faster to generate.
Not sure why some have downvoted me. It's easy to verify.
time dd if=/dev/zero of=file1.bin bs=1M count=600
600+0 records in
600+0 records out
629145600 bytes (629 MB) copied, 1.57948 s, 398 MB/s
real 0m1.651s
user 0m0.004s
sys 0m0.688s
time dd if=/dev/urandom of=file2.bin bs=1M count=600
600+0 records in
600+0 records out
629145600 bytes (629 MB) copied, 37.7828 s, 16.7 MB/s
real 0m37.786s
user 0m0.004s
sys 0m37.784s
I didn't downvote, but /dev/urandom isn't a particularly large bottleneck for any recent machine. I've got a 4 generation old I5 (3570) dd of /dev/urandom gets 300MB/sec for me. SATA is only capable of twice that, so it's not a particularly large bottleneck.
I do wonder what machine you used that's 20 times slower than a 4 generation old i5.
Thanks for this. I actually spent a bit of time playing around and learning about dd based on the above. I found that on my machine it is also slower as well. Never really had a need to use dd even with many years of playing with Unix.
I am not sure what the other comments are going on about, but let me give you a little bit of my perspective, since I have a few years of experience in the HDD industry.
An all zeroes pattern would look nothing like all zeroes on the media. Modern read/write channels use a scrambler, RLL, and LDPC, which scrambles the data, limits the length of long magnets (since the heads don't like DC signals,) and then parity bits. From a signal processing perspective, writing random data will not look much different from all zeros.
One thing to keep in mind, however; if you tell the drive to write a large range of LBAs to the same pattern, depending on the firmware, it might only write one physical sector and point every LBA in that range to that physical sector. So now your data only has the first sector overwritten. If someone hacks the firmware in a way that allows reading of physical sectors, they can get your data.
Might be something to be said for it being an obvious overwrite in some cases; /dev/urandom overwrite might be indistinguishable from an encrypted drive (for which you cannot provide any means to decrypt), which might be a problem in some jurisdictions, or if subpoenaed after the overwrite, etc.
That said I've typically followed any overwrites, random or zero-based, with use of ATA secure erase commands, which might be equally bad.
Linux /dev/random is pretty good. For anyone trying to reverse engineer the previous state of the disk it's much easier to substract out all zeros as opposed to a pseudo random sequence. Especially if the attacker doesn't have the pseudo random number generators full state.
Also keep in mind that with SSDs that have significant smarts for compression, trim, deduplication, benchmark cheating, minimizing write amplification, and related. Writing a pseudorandom sequence is more likely to actually overwrite almost 100% of the disk. Sure bad sectors that are remapped won't be, but the rest should.
Even better if you just use full disk encryption and throw away the key. Also the "secure erase" functionality is a good start, but if you aren't the trusting type it's best to wipe then overwrite.
Not sure why some have downvoted me. It's easy to verify.