All of lore.kernel.org
 help / color / mirror / Atom feed
From: test532@codingninjas.org
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] Random fill
Date: Mon, 31 Aug 2009 09:23:03 -0400	[thread overview]
Message-ID: <200908310923.03429.test532@codingninjas.org> (raw)
In-Reply-To: <874orow3rj.wl%htd@fancy-poultry.org>

> At Mon, 31 Aug 2009 06:50:39 -0400,
> test532@codingninjas.org wrote:
> 
> Thanks for your polite explaining so far!
> 
> > Because the point of filling with random data is to eliminate the
> > possibility of being able to tell where real data is stored.
> 
> Yes, that's clear.
> 
> > If the random data is cracked by using a known plaintext attack, then the
> > benefit of having this random data is nullified.
> 
> To crack the random data, the attacker must be able to distinguish them
>  from the "real" data. AS far as I know, if the key after a nullifiying
>  action via dmcrypt is wiped, the disk is filled with pseudorandom data and
>  ciphertext of the real data. For a known plaintext attack to work, one
>  must have the plaintext and the corresponding block of ciphertext
>  resulting in encryting this plaintext, ...

The truth in what you say above does make it difficult, but the amount of 
difficulty depends on how full the drive is. On a mostly empty drive, the 
probability of guessing correctly where the plain text equals zeros is fairly 
high. The further from mostly empty the drive becomes, the less likely success 
becomes.

> but that is not possible in this
>  scenario. No one can distinguish between the real ciphertext (encrypted by
>  a wholly different key) and the filling with zeroes.

> 
> The aim of a known plaintext attack is to find the key, but it has been
> irrevocably wiped, and the real text is encrypted by a totally different
>  key, in fact.
> 
> Sorry, but I can not see at all how a procedure which uses /dev/zero and
> dmcrypt to fill a partition with pseudorandom data could weaken the whole
> encryption / reduce the time for an attack on the real ciphertext at all.
> 

> Besides, AES is not vulnerable to known plaintext attacks, as far as I
>  know.

As far as you or I know. But I can guarantee you that someone out there knows 
more and isn't saying. How much more? I don't want to bet my data on it.

My operating system as it is right now has no vulnerabilities in it that I 
know of. That doesn't mean that I am going to turn off SELinux on the machine, 
because I know there is at least a possibility of vulnerabilities, and that is 
enough reason to take any extra precautions that are reasonable.

Sam

> 
> 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
> 

  reply	other threads:[~2009-08-31 13:24 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-29 19:58 [dm-crypt] Random fill Stroker
2009-08-30 12:07 ` Heinz Diehl
2009-08-30 14:07   ` Rick Moritz
2009-08-30 14:28     ` Heinz Diehl
2009-08-30 15:48       ` Rick Moritz
2009-08-30 20:54     ` test532
2009-08-31 10:38       ` Heinz Diehl
2009-08-31 10:50         ` test532
2009-08-31 12:45           ` Heinz Diehl
2009-08-31 13:23             ` test532 [this message]
2009-08-31 16:50               ` Heinz Diehl
2009-08-30 16:32 ` Arno Wagner
2009-09-01  9:24 ` Roscoe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200908310923.03429.test532@codingninjas.org \
    --to=test532@codingninjas.org \
    --cc=dm-crypt@saout.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.