From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46785) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V1eQP-0005Wl-SG for qemu-devel@nongnu.org; Tue, 23 Jul 2013 11:22:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V1eQO-0007td-4D for qemu-devel@nongnu.org; Tue, 23 Jul 2013 11:22:53 -0400 Received: from mail-ea0-x22c.google.com ([2a00:1450:4013:c01::22c]:35357) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V1eQN-0007tQ-Tc for qemu-devel@nongnu.org; Tue, 23 Jul 2013 11:22:52 -0400 Received: by mail-ea0-f172.google.com with SMTP id q10so4634724eaj.31 for ; Tue, 23 Jul 2013 08:22:51 -0700 (PDT) Date: Tue, 23 Jul 2013 17:22:47 +0200 From: Stefan Hajnoczi Message-ID: <20130723152247.GC14190@stefanha-thinkpad.redhat.com> References: <20130723124706.GB5002@irqsave.net> <20130723130053.GW2477@redhat.com> <20130723144033.GE5002@irqsave.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20130723144033.GE5002@irqsave.net> Subject: Re: [Qemu-devel] QCOW2 cryptography and secure key handling List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?iso-8859-1?Q?Beno=EEt?= Canet Cc: kwolf@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com On Tue, Jul 23, 2013 at 04:40:34PM +0200, Benoît Canet wrote: > > More generally, QCow2's current encryption support is woefully inadequate > > 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. Using > > the LUKS data format precisely would be good from a data portability > > POV, since then you can easily switch your images between LUKS encrypted > > block device & qcow2-with-luks image file, without needing to re-encrypt > > the data. > > I read the LUKS specification and undestood enough part of it to understand the > potentials benefits (stronger encryption key, multiple user keys, possibility to > change users keys). > > Kevin & Stefan: What do you think about implementing LUKS in QCOW2 ? 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. 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 the VM should see the data. A big win with LUKS is that you can change the passphrase without re-encrypting the data. Stefan