From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:33180)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <benoit.canet@irqsave.net>) id 1V1djl-0003Lh-GL
	for qemu-devel@nongnu.org; Tue, 23 Jul 2013 10:38:52 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <benoit.canet@irqsave.net>) id 1V1djj-0007WQ-VX
	for qemu-devel@nongnu.org; Tue, 23 Jul 2013 10:38:49 -0400
Received: from nodalink.pck.nerim.net ([62.212.105.220]:47534
	helo=paradis.irqsave.net) by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <benoit.canet@irqsave.net>) id 1V1djj-0007WC-Mm
	for qemu-devel@nongnu.org; Tue, 23 Jul 2013 10:38:47 -0400
Date: Tue, 23 Jul 2013 16:40:34 +0200
From: =?iso-8859-1?Q?Beno=EEt?= Canet <benoit.canet@irqsave.net>
Message-ID: <20130723144033.GE5002@irqsave.net>
References: <20130723124706.GB5002@irqsave.net>
	<20130723130053.GW2477@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
In-Reply-To: <20130723130053.GW2477@redhat.com>
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Qemu-devel] QCOW2 cryptography and secure key handling
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: "Daniel P. Berrange" <berrange@redhat.com>
Cc: =?iso-8859-1?Q?Beno=EEt?= Canet <benoit.canet@irqsave.net>, kwolf@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com

> More generally, QCow2's current encryption support is woefully inadequa=
te
> from a design POV. If we wanted better encryption built-in to QEMU it i=
s
> 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 encrypte=
d
> block device & qcow2-with-luks image file, without needing to re-encryp=
t
> the data.

I read the LUKS specification and undestood enough part of it to understa=
nd the
potentials benefits (stronger encryption key, multiple user keys, possibi=
lity to
change users keys).

Kevin & Stefan: What do you think about implementing LUKS in QCOW2 ?

Best regards

Beno=EEt