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
