l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
July 7: Social gathering
Next Installfest:
Latest News:
Jun. 14: June LUGOD meeting cancelled
Page last updated:
2009 Sep 16 11:56

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
[no subject]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[no subject]

> entropy from the system. When an event happens, it may be worth one or
> two bits. Last time I wrote a program that read from that device, it
> seemed that I got a number of bytes, and then I had to wait as various
> events occured to the system. That is why they often tell you to move the
> mouse around when generating keys. It generates entropy for the system.

Yes, /dev/random blocks when there isn't enough entropy, thus /dev/urandom above.

> You can feed that data from /dev/urandom into AES as the key, then
> use Cipher Block Chaining so that it looks more random. Essentially,

Seems a bit silly, /dev/urandom does this already for you.  If interested you
might like RFC 1750 "Randomness Recommendations for Security".

> you are using the /dev/urandom as the key to produce cipher text.
> I believe dban does this. 

Seems a bit silly.  So if you use /dev/urandom for the key for AES, what do
you actually encrypt?

> If you wipe with /dev/zero, then the adversary could be correct for
> half the bits assuming that they are equaly distributed!

Er, right.  How is that a problem?   Say I buy a new disk full of zeros, it
has likely around half the bits identical to your disk.  The trick is I don't
know which ones.  Sure for each bit I have a 50% chance.  But even guessing 64
in a row is 1/2^64 or so which makes it rather unlikely.

Kinda reminds me of printing out all the ssn numbers and then saying I have
you SS number in that list... I've violated your privacy... then again I don't
know which one it is.

Basically with todays drive technology what you write is what you get, the
"track edges" are gone, there exists no practical way to reads the bits from
previous reads.  I just picked /dev/urandom becuase it's cheap, easy to
compute, er, oops.  Looks like it would be faster to write all zeros then all

At least the 2 faster machines I have access to only manage 7.5MB/sec, any
disk from the last few years should manage 40-50MB/sec and if it's from the
last year or so likely double that or more.

So what would be faster and more protective (but not as much as a secure
erase) could be any two patterns.  0 then 1, of if you prefer any byte then
it's compliment.
vox-tech mailing list

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
Appahost Applications
For a significant contribution towards our projector, and a generous donation to allow us to continue meeting at the Davis Library.