From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44101) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V1fTI-00087O-Ud for qemu-devel@nongnu.org; Tue, 23 Jul 2013 12:29:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V1fTH-0000y2-N5 for qemu-devel@nongnu.org; Tue, 23 Jul 2013 12:29:56 -0400 Received: from mx1.redhat.com ([209.132.183.28]:16787) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V1fTH-0000x0-EK for qemu-devel@nongnu.org; Tue, 23 Jul 2013 12:29:55 -0400 Date: Tue, 23 Jul 2013 16:40:03 +0100 From: "Daniel P. Berrange" Message-ID: <20130723154003.GH2477@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=utf-8 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 Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: =?utf-8?Q?Beno=C3=AEt?= Canet , kwolf@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com On Tue, Jul 23, 2013 at 05:22:47PM +0200, Stefan Hajnoczi wrote: > On Tue, Jul 23, 2013 at 04:40:34PM +0200, Beno=C3=AEt 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 haven'= t > looked at qcow2 encryption in the past because fairly few people > actually use it. >=20 > One use-case I have heard about is qcow2 files over NFS. The network > and the storage system should not see guest data. Only the host and th= e > VM should see the data. Yep, that is the core usecase. You are securing the system such that only the VM host administrator/processes can compromise the data. It is protected against malicious storage and/or network administrators. > A big win with LUKS is that you can change the passphrase without > re-encrypting the data. Other benefits of LUKs are - Strong encryption key, even if the passphrase itself is weak - Support for multiple passphrases - Support for arbitrary different encryption algorithms / settings - Ability to detect whether the passphrase is correct or not rather than just decrypting to produce garbage Regards, Daniel --=20 |: http://berrange.com -o- http://www.flickr.com/photos/dberrange= / :| |: http://libvirt.org -o- http://virt-manager.or= g :| |: http://autobuild.org -o- http://search.cpan.org/~danberr= / :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vn= c :|