Re: Re: why init crypto partition with random data?

[junk <junk@xxxxxxxxxxxxx>]

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