[ale] A little math

[David Tomaschik]

Scott Castaline wrote:
> Okay I've got a dumb question for you math types. How long should it 
> take to fill a 1TB hdd with random data using
> "dd if=/dev/urandom of=/dev/sd"? I've done some more searching and found 
> some numbers and if I figured them right I'm looking at about 8 days. Is 
> this accurate?
>   
I know this has been discussed quite a bit, and I apologize for
addressing some things from various points along the thread, but I
thought I'd clear some things up regarding random data before encrypting
disks.

1.) Pseudorandom data (e.g., /dev/urandom) is, with a very high degree
of certainty, good enough for this application.  Any decent pseudorandom
generator (PRNG) has been tested to determine vulnerability to pattern
analysis and should have achieved reasonable results.  When you write
your encrypted data over parts of the stream, you likely foil any
ability to analyze the PRNG.  That being said, /dev/urandom does attempt
to use the kernel's available entropy pool, and consequently is MUCH
slower than other cryptographic PRNGs.  Generating 50M of random data on
my system with /dev/urandom takes ~8.488sec.  Doing so using "openssl
rand" (another high-quality PRNG) takes 1.547s.  Use openssl rand for a
7x speedup.  It should be able to overwrite a 1 TB drive in 9 hours.
    OpenSSL Rand: 32.3 MB/s
    /dev/urandom: 5.9 MB/s

2.) Overwriting a hard drive with random data is only useful for
block-level encryption.  Any file-level encryption (e.g., GPG, eCryptFS,
etc.) gains NO benefit from the random overwrite.  In these cases, there
is an [underlying] filesystem that would point a determined attacker to
your data.

3.) Consider your attacker.  Most encryption is intended to prevent your
data being compromised if your laptop is stolen, etc.  Attackers without
a background in cryptanalysis are likely to be foiled by even the
simplest schemes, and random overwriting is overkill and a waste of
time/energy/hard drive life.  IMO, most stolen hard drives/systems will
have your average thief confused by the Linux splash screen, or when it
fails to mount in Windows.

4.) http://xkcd.com/538/


-- 
David Tomaschik, RHCE
Moderator, LinuxQuestions.org
http://www.tuxteam.com
david at tuxteam.com [GPG: 0x6D428695]


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 898 bytes
Desc: OpenPGP digital signature
Url : http://mail.ale.org/pipermail/ale/attachments/20100212/c128e1af/attachment.bin