4 ms·

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

cryptoz 9y ago
Because you'd be leaving behind traces of the overwrite, depending on the security of the random number generator. 0s leaves behind no patterns.
- tdurden 9y ago
  Aren't all 0's a more obvious pattern indicating an overwrite?
- sliken 9y ago
  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.
w8rbt 9y ago
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
- sliken 9y ago
  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.
- rini17 9y ago
  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
  - sliken 9y ago
    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.
- gist 9y ago
  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-so-slow-when-using-dd https://superuser.com/questions/359599/why-is-my-dev-random-... (This raises the question of why using openssl (per other comment) makes it faster.)
- pstrateman 9y ago
  Linux kernels after 4.8 use chacha which is significantly faster than the previous implementation. (~250MB/s on my laptop).
Lramseyer 9y ago
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.
syntheticnature 9y ago
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.
deleted 9y ago
[deleted]

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

tdurden 9y ago
Aren't all 0's a more obvious pattern indicating an overwrite?
sliken 9y ago
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.

w8rbt 9y ago

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

sliken 9y ago
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.
rini17 9y ago
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
- sliken 9y ago
  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.
gist 9y ago
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-so-slow-when-using-dd https://superuser.com/questions/359599/why-is-my-dev-random-... (This raises the question of why using openssl (per other comment) makes it faster.)
pstrateman 9y ago
Linux kernels after 4.8 use chacha which is significantly faster than the previous implementation. (~250MB/s on my laptop).

Lramseyer 9y ago

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.

syntheticnature 9y ago

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.

deleted 9y ago

[deleted]