From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from v4.tansi.org (ns.km33513-03.keymachine.de [87.118.94.3]) by mail.saout.de (Postfix) with ESMTP for ; Fri, 18 Feb 2011 21:07:19 +0100 (CET) Received: from gatewagner.dyndns.org (84-74-164-239.dclient.hispeed.ch [84.74.164.239]) by v4.tansi.org (Postfix) with ESMTPA id 42FC2204F01 for ; Fri, 18 Feb 2011 21:07:19 +0100 (CET) Date: Fri, 18 Feb 2011 21:07:18 +0100 From: Arno Wagner Message-ID: <20110218200718.GA12395@tansi.org> References: <20110218173302.GA9234@tansi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [dm-crypt] LUKS and LVM List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de On Sat, Feb 19, 2011 at 04:53:20AM +1100, Eric Bauman wrote: > Thanks for the reply! > > With regards to the multiple containers, the configuration I'd run > across was one container per partition, with the key for each stored in > /. When the system was booted, the passphrase was entered, and each > partition's container opened and mounted automatically. If they are not combined into something larger, that is fine. If they are (RAID or other LVM action), then I would allways forst construct the whole device and then encrypt, i.e. encryption on top of block layer and below filesystem. > On 19/02/2011, Arno Wagner wrote: >>> I typically randomise my block device before creating a LUKS container >>> on it. Option 2 would seem to reduce the effectiveness of this because >>> LVM will give clues to where real data might be. >> >> I don't follow. That encrypted data is present is obvious from >> the LUKS header. What is in the container(s) is as opaque in >> (1) as it is in (2), given that cryptographically strong >> randomness is used for the overwrite (I use plain dm-crypt >> with a random password and overwrite with conventional, >> mt19997-generated randomness). > > I meant not that the data protection of one was better than the other, > but rather in (2) LVM will store in plain-text both the start and end > offset of the partition. So perhaps an attacker would have a better idea > of where data is. Comparing knowing the partition starts at X and ends > at Y, there is probably some encrypted data in there somewhere, versus a > giant container with no indication of structure (could be encrypted data > or could be random garbage). LUKS has a header per container. Also, knowing were the encrypted data is does not help the attacker, unless he/she can repeatedly access the computer. In that case, all is luikely lost anyways. Arno -- Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans If it's in the news, don't worry about it. The very definition of "news" is "something that hardly ever happens." -- Bruce Schneier