Ahh, I have been going under the assumption that the encryption algorithms being used are not vulnerable to known plaintext attacks. I think this to be reasonable, if it's not I'm skeptical that prefilling a partition with pseudorandom data is going to help much at all (one can still take guesses at known plaintext in the same way as if you didn't prefill). Good point regarding knowing something about the structure of the files, I can imagine one working out the number of files, and approximate sizes. How doable this is with filesystem X is certainly beyond me. And the accuracy of such information is a guestimate at best, maybe I had 20 1gb temp files, then deleted them and now the filesystem contains only a single 1kb jpeg. I can't see how one could tell the difference. On 2/23/07, junk <junk@xxxxxxxxxxxxx> wrote:
Roscoe wrote: > My two cents: > > > I personally think that page should be reworded. > "This makes breaking the passphrase so much harder" Says who? > > > Overwriting the previous contents of the HD does have some value > regarding secure deletion IMHO, just not very much - someone can't > just run `strings /dev/sda` after you've zeroed out a hard drive, > rather they need some specialized hardware and skills. > > > As for writing random data to the disk for the purposes of obscuring > the ciphertext location: > > So what if they do know the exact boundaries of the ciphertext? The > ciphertext doesn't need to be kept secret. That's the whole idea of > ciphertext. > That's true only if the plaintext is genuinely unknown. This is not the case for filesystem data - it contains many elements that are pretty predicatable. Not overwriting the disk with random data before creating an encrypted file system on it might give an attacker useful information about the boundaries between unused portions of the disk and files system structures and the files themselves. This in turn could be used to mount a known plaintext attack, particularly if the attacker knows your operating system/distribution/file system type -- jeek > On 2/23/07, Michael Schmidt <drmike@xxxxxxx> wrote: >> See my comments in-line. >> >> Marc Schwartz <marc_schwartz@...> writes: >> >> > >> > Michael Schmidt 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 >> > >> > Two different issues: >> > >> > 1. Filling the disk with random data obfuscates the difference between >> > data that has been encrypted (which is in theory random) and data that >> > has not been encrypted, which will not be random. >> > >> > In other words, you are in effect hiding any boundaries between cipher >> > text and clear text. This makes it more difficult for an attacker to >> > distinguish the two and also to potentially have both cipher text and >> > clear text for the same data, aiding in an attack. >> >> I do understand this. But what benefit would an attacker draw from >> being able >> to make this distinction? >> I also understand that the chance for the existance of a corresponding >> plaintext - ciphertext pair increases. However, an attacker would not >> get any >> hint where the corresponding ciphertext actually resides, would he? >> >> In general, I'm just wondering whether these are just assumptions or >> whether >> there are real scientific results fueling this attack scenario. >> >> > >> > 2. Simply filling the disk with random data does NOT sufficiently >> > overwrite old data to the point of no longer being recoverable. >> > >> > This is basic electromagnetics. See information on data remanance, >> such as: >> > >> > http://en.wikipedia.org/wiki/Data_remanence >> > >> > and many others. >> >> Yes, I'm aware of this. >> >> > >> > HTH, >> > >> > Marc Schwartz >> >> Thanks, 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 >> >> > > --------------------------------------------------------------------- > 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 > --------------------------------------------------------------------- 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
--------------------------------------------------------------------- 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
