From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from molly.corsac.net (molly.corsac.net [IPv6:2002:4ec0:442e::1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Thu, 19 May 2011 11:14:58 +0200 (CEST) From: Yves-Alexis Perez In-Reply-To: <4DD4DA3C.90303@redhat.com> References: <20110518152417.15529442@Haruhi.lan.labor-bochum.net> <1305755598.15947.2.camel@hidalgo> <4DD4C126.3030709@redhat.com> <1305792110.9280.4.camel@oban> <4DD4DA3C.90303@redhat.com> Content-Type: text/plain; charset="utf-8" Date: Thu, 19 May 2011 11:14:56 +0200 Message-ID: <1305796496.9280.10.camel@oban> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: Re: [dm-crypt] DM-Crypt resistance against Cold Boot Attacks List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Milan Broz Cc: dm-crypt@saout.de On jeu., 2011-05-19 at 10:52 +0200, Milan Broz wrote: > On 05/19/2011 10:01 AM, Yves-Alexis Perez wrote: > > On jeu., 2011-05-19 at 09:05 +0200, Milan Broz wrote: > >> On 05/18/2011 11:53 PM, Yves-Alexis Perez wrote: > >>> If you read the paper, you'll noticed there's nothing to change to > >>> dm-crypt, as the cypher is registered in the Crypto-API, it can be used > >>> directly. > >> > >> TBH dmcrypt keeps its own copy of key (because key it is still part > >> of the device-mapper mapping table so it must be available for > >> status commands). > > > > In that case it'll be the “dummy” key. > > The logic now works that table line received from dmcrypt > is directly usable - cryptsetup uses that e.g. for resize. > Replacing the key with zeroes or something will break this. I don't know enough dm-crypt arch, but aiui from the paper, everytime you use the crypto-api to do stuff, it'll use the key in CPU debug registers and not the dummy key. Do you mean cryptsetup resize doesn't use the crypto-api (and will thus fail)? > > >> So there are some changes needed but basically technicaly unrelated > >> to that patch. > >> (This will hopefully change with new mapping table format soon.) > > > > Needed for what? > > You mean new table format? No, I meant the “changes needed” :) > > ... etc. > > >> > >> Anyway, it must be accepted into kernel crypto layer first. > > > > I'm not even sure it'll be submitted though. > > So it is just academic exercise for conferences? No idea. Just to be clear, I'm in now way associated to that paper, I just found it interesting after seeing the first mail in thread and wanted to add my views about the suppossingly needed changes to dm-crypt. But looking at their website and the papers I didn't see anything about submitting the patch upstream. It might not be acceptable to use the debug registers in mainline kernel though. > > For the AES-NI one, if the hypervisor supports it (they tested on KVM) > > yes (though the vm registers are stored in the host ram anyway). > > Yes, that was my point. (AES-NI works for guests but bare hw has > of course limited hw resources.) Note that I'm not sure it's a good idea to use encryption in a guest anyway, at least not to protect from the host. Regards, -- Yves-Alexis