Many tutorials suggest that i should fill a disk with /dev/urandom instead of /dev/zero if i want it to be unrecoverable.
Whatever you do, do not use /dev/urandom
.
On my i7-3770, /dev/urandom
produces an astonishing 1 GB of pseudo-randomly generated data per minute. For a 4 TB hard drive, a single wipe with /dev/urandom
would take over 66 hours!
If you absolutely must use pseudo-randomly generated data (more on that below), at least use a decently fast way of generating it. For example
openssl enc -aes-128-ctr -pass file:/dev/random 2>/dev/null | tail -c+17
prints an infinite stream of bytes. It uses AES in CTR mode and a password read from /dev/random
, so it's cryptographically secure for any hard drive smaller than 1,000,000 TB.
It's also fast. Very fast. On the same machine, it managed to generate 1.5 GB per second, so it's 90 times faster than /dev/urandom
. That's more than any consumer-level hard drive can handle.
[I]s this just very specialized people (read government agencies) who can recover a zero-filled disk, or something your average geek can do?
In Overwriting Hard Drive Data: The Great Wiping Controversy, the authors conclude that overwriting a pristine drive (only used for the test) once with non-random data lower the probability of recovering a single bit correctly to 92%. This means that a single byte (one ASCII character) can be recovered with only 51% probability; and there's no way of telling if the byte has been recovered correctly or not.
In real world scenarios (slightly used drive), the probability drops to 56% for a single bit and merely 9% for a single byte.
They took a new drive, wiped it three times to simulate short-term usage, wrote a short text to it and wiped the drive once with non-random data. These were the results:
Original text:
Secure deletion of data - Peter Gutmann - 1996
Abstract
With the use of increasingly sophisticated encryption systems, an attacker
wishing to gain access to sensitive data is forced to look elsewhere for information. One avenue of attack is the recovery of supposedly erased data
from magnetic media or random-access memory.
Recovered text:
¡ÄuÜtÞdM@ª""îFnFã:à•ÅÒ̾‘¨L‘¿ôPÙ!#¯ -×LˆÙÆ!mC
2´³„‡·}NŽýñêZØ^›l©þì®·äÖŒv¿^œº0TÏ[ªHÝBš¸ð
7zô|»òëÖ/""º[ýÀ†,kR¿xt¸÷\Í2$Iå""•ÑU%TóÁ’ØoxÈ$i
Wï^™oËS²Œ,Ê%ñ ÖeS» eüB®Èk‹|YrÍȶ=ÏÌSáöp¥D
ôÈŽ"|ûÚA6¸œ÷U•$µM¢;Òæe•ÏÏMÀùœç]#•Q
Á¹Ù""—OX“h
ÍýïÉûË Ã""W$5Ä=rB+5•ö–GßÜä9ïõNë-ߨYa“–ì%×Ó¿Ô[Mãü
·†Î‚ƒ‚…[Ä‚KDnFJˆ·×ÅŒ¿êäd¬sPÖí8'v0æ#!)YÐúÆ©
k-‹HÈø$°•Ø°Ïm/Wîc@Û»Ì"„zbíþ00000000000000000
2I'm adding this as a comment because I'm not 100% certain myself, but from using various programs to do this, there's often the option to set how many passes of zero-writes you want to do, which leads me to believe that even writing once doesn't totally obliterate the data. Writing random characters would make it harder for baddies to tell which layers or whatever were good data, and which are just random jibberish. – Chris Stauffer – 2012-12-21T20:21:27.623
I think this program is all you'll ever need for this type of thing (DBAN), the documentation extensively covers this topic.
– Breakthrough – 2012-12-21T23:05:00.600