From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-bw0-f50.google.com (mail-bw0-f50.google.com [209.85.214.50]) by mail.saout.de (Postfix) with ESMTP for ; Tue, 11 Jan 2011 17:35:27 +0100 (CET) Received: by bwg12 with SMTP id 12so22669445bwg.37 for ; Tue, 11 Jan 2011 08:35:27 -0800 (PST) Sender: Richard Zidlicky Date: Tue, 11 Jan 2011 17:35:13 +0100 From: Richard Message-ID: <20110111163513.GA16839@rz> References: <4D266EF9.6090904@gmail.com> <20110111000816.GC31936@rz> <20110111091147.GA4260@tansi.org> <4D2C3189.8080708@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D2C3189.8080708@redhat.com> Subject: Re: [dm-crypt] Dmcrypt and hibernate key disclosure List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Milan Broz Cc: dm-crypt@saout.de On Tue, Jan 11, 2011 at 11:31:37AM +0100, Milan Broz wrote: > Sorry I do not follow this thread but Fedora uses by default > (= "encrypt the whole system" checkbox in installer) unencrypted > boot partition (where initramdisk resides) and LUKS encrypted PV on > the second partition, on top of it is root and swap LVs. > (So the whole system is encrypted except boot initramfs.) > > The same is quite common in other distros too. > > During boot, initramfs must ask for passphrase to PV, the same for hibernate > (suspend to disk - ram image is stored to swap partition LV). to sum up, I am quite pleased with Fedora in this respect. Makes full system encryption including safe hibernation as trivial as checking a checkbox during installation. > What is not safe is suspend to RAM. Maybe someone should start to use > luksSuspend to at least clear encryption key from memory but it is not > as easy implement as it seems:) surely luksSuspend would make it safer but still complete RAM would be left unprotected which can be a lot of information. Did anyone look inot encrypting RAM before suspend? As it is now it is also not trivialy broken - getting the filesystems would involve breaking screen saver locking, breaking in through network or other interfaces or freezing the computer to retrieve and examine ramchips. Otoh chances are not bad that the average adversary upon seeing a locked session will just do a stupid reboot and loose every chance to hack into it. > Btw do not afraid of LVM in this scheme - mapping is just linear, so > the only mapping operation in kernel is adding offset and switching device > so there should be no measurable performance problem (there is no cache > or so). seems dm or something else is slow enough that id does not matter at all. Richard --- Name and OpenPGP keys available from pgp key servers