Hacker News Reader

Comment by montzark | Hacker News Reader

Just wondering, why zeroes not /dev/urandom for example?

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.

I had similar problem with urandom, instead used openssl like this and it's fast enough:

openssl enc -aes-256-cbc -in /dev/zero -out /dev/sdX

Interesting. Looks like for newer kernels (newer than 4.8) that's about twice as fast. But for older kernels it's around 20 times as fast.

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.

This post appears to have the reason:

https://superuser.com/questions/359599/why-is-my-dev-random-...

(This raises the question of why using openssl (per other comment) makes it faster.)

Linux kernels after 4.8 use chacha which is significantly faster than the previous implementation. (~250MB/s on my laptop).

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.

Because you'd be leaving behind traces of the overwrite, depending on the security of the random number generator. 0s leaves behind no patterns.

Aren't all 0's a more obvious pattern indicating an overwrite?

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.

Reply on news.ycombinator.com