3 ms·
When you overwrite the disk, you say you should use dd if=/dev/random, but the reason why this is much slower is because /dev/random blocks. Use /dev/urandom be
by tuxxy 9y ago
When you overwrite the disk, you say you should use dd if=/dev/random, but the reason why this is much slower is because /dev/random blocks. Use /dev/urandom because it doesn't block -- Before you ask, yes this is still secure.
Or you can use dm-crypt and create a temporary container with a random key to wipe it. This will be a bit faster than the above. See the Arch wiki for details[1]
[1] - https://wiki.archlinux.org/index.php/Dm-crypt/Drive_preparation#dm-crypt_specific_methods https://wiki.archlinux.org/index.php/Dm-crypt/Drive_preparat...
- noinsight 9y agoOr, you can use the (S)ATA Secure Erase[1] command which was designed from the start to securely wipe a hard disk and should handle wiping reserve space etc. properly. [1] https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase
- Nauxuron 9y agoApparently, this is not always implemented correctly on SSDs. It should take quite some time, but if it finishes after a few seconds, it probably didn't really wipe your SSD securely.
- oxplot 9y agoMost SSDs should be encrypted by default and all secure erase would do is to wipe the encryption key and generate a new one which takes no time and does effectively and securely wipe the entire disk.
- brobinson 9y agoAnd don't forget `oflag=direct` if you use dd directly
- SCdF 9y agoOn the subject, is there any evidence that wiping to anything more complicated than 0s is actually helpful? Are there are practical attacks where you take a zero'd hard drive and derive data from it that you wouldn't have been able to derive were it written over randomly?