Jan Reusch wrote:
Marc Schwartz schrieb:
(thing about filling the partition with random data before creating
crypted device)
hi,
sorry to bother you again.
in a german computer magazine (namely c't) there's an article about
luks and dm-crypt.
they also say you have to fill the partition with random data (due to
reasons we all know)
but they do a little trick.
they say /dev/zero is much faster than /dev/urandom (which should be
true ;) )
so they whipe the first few m'bytes of the plan device with
/dev/urandom (thats where the luks header will be written to),
luksFormat the device, set it up and whipe the new encrypted device
with zeros.
so the zeros get encrypted and voila, random data on the partition.
my question is:
somebody who knows this technique now knows the plain "data" (or at
least for a long time huge parts of it) could he get information about
the master key he else wouldn't have?
thank you for your time.
Jan
This seems to be going after convenience at the expense of security. I
should note for context, that on my system (a Dell 5150 Inspiron laptop
with a 3.2 Ghz P4, 2 Gb of RAM and a 7200 RPM 60 Gb HD) it takes about
10 minutes per Gb with /dev/urandom.
This /dev/zero approach presumes that the result of the encryption
algorithm on a very long stream of 0's is "relatively" random for the
purpose of simply making it difficult to differentiate between random
underlying noise and actual encrypted data.
That assumption will be highly dependent upon the algorithm and the key
length to a large measure as well as the comparisons of "randomness"
between this output and the output of /dev/urandom, which is a PRNG.
I can't help but consider that this would be a [much] weaker solution
than the previously discussed approach.
In addition, as you note, if one were to presumably know that this
particular approach was in fact used on a particular drive, you would
indeed be opening up the opportunity for a "known plaintext" attack with
a VERY long stream of output from the encryption process. This would
often be facilitated greatly by the user doing a poor job of key
generation/selection with insufficient entropy.
This would be a significant hole.
If you want to do some additional reading on these issues, here is a
staring point:
http://en.wikipedia.org/wiki/Category:Cryptographic_attacks
and of course Bruce's texts that I referenced in a prior reply.
HTH,
Marc Schwartz
---------------------------------------------------------------------
- http://www.saout.de/misc/dm-crypt/
To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx
For additional commands, e-mail: dm-crypt-help@xxxxxxxx
