From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from op7.codingninjas.org (op7.codingninjas.org [209.222.52.116]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Mon, 31 Aug 2009 15:24:37 +0200 (CEST) Received: from sschai.localnet (CPE0080c6e9d913-CM000f9f4fecc0.cpe.net.cable.rogers.com [99.249.56.245]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by op7.codingninjas.org (Postfix) with ESMTPSA id EDDD54E226C for ; Mon, 31 Aug 2009 09:24:46 -0400 (EDT) From: test532@codingninjas.org Date: Mon, 31 Aug 2009 09:23:03 -0400 References: <200908291558.58894.dmcryptmailman@strokerville.com> <200908310650.39393.test532@codingninjas.org> <874orow3rj.wl%htd@fancy-poultry.org> In-Reply-To: <874orow3rj.wl%htd@fancy-poultry.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200908310923.03429.test532@codingninjas.org> Subject: Re: [dm-crypt] Random fill List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de > 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 >