From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53173) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V1efE-0001R5-FI for qemu-devel@nongnu.org; Tue, 23 Jul 2013 11:38:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V1efC-0005Mb-Cb for qemu-devel@nongnu.org; Tue, 23 Jul 2013 11:38:12 -0400 Received: from mx1.redhat.com ([209.132.183.28]:29707) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V1efC-0005MA-2x for qemu-devel@nongnu.org; Tue, 23 Jul 2013 11:38:10 -0400 Date: Tue, 23 Jul 2013 17:38:00 +0200 From: Kevin Wolf Message-ID: <20130723153800.GD20225@dhcp-200-207.str.redhat.com> References: <20130723124706.GB5002@irqsave.net> <20130723130053.GW2477@redhat.com> <20130723144033.GE5002@irqsave.net> <20130723152247.GC14190@stefanha-thinkpad.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20130723152247.GC14190@stefanha-thinkpad.redhat.com> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] QCOW2 cryptography and secure key handling List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: =?iso-8859-1?Q?Beno=EEt?= Canet , qemu-devel@nongnu.org, stefanha@redhat.com Am 23.07.2013 um 17:22 hat Stefan Hajnoczi geschrieben: > On Tue, Jul 23, 2013 at 04:40:34PM +0200, Beno=EEt Canet wrote: > > > More generally, QCow2's current encryption support is woefully inad= equate > > > from a design POV. If we wanted better encryption built-in to QEMU = it is > > > best to just deprecate the current encryption support and define a = new > > > qcow2 extension based around something like the LUKS data format. U= sing > > > the LUKS data format precisely would be good from a data portabilit= y > > > POV, since then you can easily switch your images between LUKS encr= ypted > > > block device & qcow2-with-luks image file, without needing to re-en= crypt > > > the data. > >=20 > > I read the LUKS specification and undestood enough part of it to unde= rstand the > > potentials benefits (stronger encryption key, multiple user keys, pos= sibility to > > change users keys). > >=20 > > Kevin & Stefan: What do you think about implementing LUKS in QCOW2 ? >=20 > Using standard or proven approachs in crypto is a good thing. I think the question is how much of a standard approach you take and what sense it makes in the context where it's used. The actual encryption algorithm is standard, as far as I can tell, but some people have repeatedly been arguing that it still results in bad crypto. Are they right? I don't know, I know too little of this stuff. So what can we take from LUKS, how would it be integrated in qcow2 and what will the final result be like then? For example, currently qcow2 doesn't encrypt metadata. Is this a problem? If metadata is encrypted, you have some blocks whose content is pretty predictable. Does this hurt? I guess if you want to plausibly claim that some new code does better, some questions like these have to be answered. Kevin