Stefan Schönleitner <dev.c0debabe@...> writes: > > Hi, > > first if you use dmcrypt or any other disk encryption the data you > write to the disk is encrypted. > This also means that empty disk space does not contain crypto data which tells > an attacker at least how much disk space on your crypto disk is used and, most > important, he can also identify the ciphertext "blocks" and eventually mount > e.g. statistical attacks on them. This sounds still quite fuzzy to me (well - I'm not a cryptographer...). Do you - by chance - have any reference (paper etc.) for such statistical attacks? > Anothing thing is that why a perfect encryption algorithm should have it's > output equally distributed there are some deviations from that with some real > life applications (especially the chaining modes can be dangerous). I don't understand this. Do you have any example? And how does it relate to the initial issue that an attacker is supposed to draw a benefit from identifying plaintext? > Have a look at the different cipher block chaining modes, the wikipedia > article also contains an example of non equally distributed ciphertext in the > now possibly obsolete ECB chaining mode. > http://en.wikipedia.org/wiki/Cipher_block_chaining Well - I think that ECB is out of question for any cryptographically responsible full disk encryption. I'm surprised to see it as dm-crypt option at all. However, with CBC, I don't see the point, how identifying cipher text (I asssume, by its zero redundancy) would help breaking it. OK, an attacker could concentrate his attacks on these areas which have been identified as encrypted data. In real world scenarios, I would assume this is something like 10 to 90 % of a partition. So this means he could make his attack more efficient by a factor of up to 10 (with only 10% encrypted). With an acknowledged algorithm and mode like AES-CBC, I don't see how a factor of 10 could seriously threaten confidentiality here. Maybe I'm missing the point... > Now, if you fill up wour disk with good random data, it will be very hard to > identify the ciphertext blocks since they look like random data. > Thus the attacker does not even know the ciphertext ;) > > greets, > stefan Thanks, Michael > > On Thu, 22 Feb 2007 12:55:09 +0000 (UTC) > Michael Schmidt <drmike@...> wrote: > > > Hi, > > > > the on-line LUKS documentation recommends for crypto-analytic reasons to > > initialize any partition that is to becom encrypted by LUKS to be initialized > > with random data (from: http://www.saout.de/tikiwiki/tiki-index.php? > > page=EncryptedDeviceUsingLUKS): > > > > Note : if you want your encryption to defeat a full cryptoanalytic attack, not > > just casual snooping, you need to fill the disk with high quality random data. > > Badblocks below justs uses 'libc' random(), but is fast (your limitation will > > be disk speed, not CPU speed). /dev/urandom is better (takes about 5 minutes > > per gigabyte on my system), /dev/random is best (takes about 1 year per > > gigabyte on my system, much too slow!). > > > > > > What's the very reason for it (besides eliminating any left-over plaintext > > data)? Is there any scientific papaer or reference backing this up? > > > > > > Thanks in advance, > > > > Michael > > > > --------------------------------------------------------------------- dm-crypt mailing list - http://www.saout.de/misc/dm-crypt/ To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx For additional commands, e-mail: dm-crypt-help@xxxxxxxx
