From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33222) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V2141-0005tj-Gm for qemu-devel@nongnu.org; Wed, 24 Jul 2013 11:33:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V213y-00017U-Vx for qemu-devel@nongnu.org; Wed, 24 Jul 2013 11:33:17 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42462) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V213y-00017H-PE for qemu-devel@nongnu.org; Wed, 24 Jul 2013 11:33:14 -0400 Date: Wed, 24 Jul 2013 16:33:04 +0100 From: "Daniel P. Berrange" Message-ID: <20130724153304.GD30336@redhat.com> References: <20130723124706.GB5002@irqsave.net> <20130723130053.GW2477@redhat.com> <20130723144033.GE5002@irqsave.net> <20130723152247.GC14190@stefanha-thinkpad.redhat.com> <20130723153800.GD20225@dhcp-200-207.str.redhat.com> <20130723155741.GI2477@redhat.com> <51EFF30E.9060102@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <51EFF30E.9060102@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: Paolo Bonzini Cc: Kevin Wolf , =?utf-8?Q?Beno=C3=AEt?= Canet , qemu-devel@nongnu.org, stefanha@redhat.com, Stefan Hajnoczi On Wed, Jul 24, 2013 at 05:30:22PM +0200, Paolo Bonzini wrote: > Il 23/07/2013 17:57, Daniel P. Berrange ha scritto: > > On Tue, Jul 23, 2013 at 05:38:00PM +0200, Kevin Wolf wrote: > >> Am 23.07.2013 um 17:22 hat Stefan Hajnoczi geschrieben: > >>> On Tue, Jul 23, 2013 at 04:40:34PM +0200, Beno=C3=AEt Canet wrote: > >>>>> More generally, QCow2's current encryption support is woefully in= adequate > >>>>> from a design POV. If we wanted better encryption built-in to QEM= U 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 portabil= ity > >>>>> POV, since then you can easily switch your images between LUKS en= crypted > >>>>> 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 u= nderstand 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 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 peo= ple > >> have repeatedly been arguing that it still results in bad crypto. Ar= e > >> they right? I don't know, I know too little of this stuff. > >=20 > > One reason that QCow2 is bad, despite using a standard algorithm, is > > that the user passphrase is directly used encrypt/decrypt the data. > > Thus a weak passphrase leads to weak data encryption. With the LUKS > > format, the passphrase is only used to unlock the master key, which > > is cryptographically strong. LUKS applies multiple rounds of hashing > > to the user passphrase based on the speed of the machine CPUs, to > > make it less practical to brute force weak user passphrases and thus > > recover the master key. >=20 > Another reason that QCow2 is bad is that disk encryption is Complicated. > Even if you do not do any horrible mistakes such as using ECB > encryption, a disk encrypted sector-by-sector has a lot of small > separate cyphertexts in it and is susceptible to a special range of att= acks. >=20 > For example, current qcow2 encryption is vulnerable to a watermarking > attack. > http://en.wikipedia.org/wiki/Disk_encryption_theory#Cipher-block_chaini= ng_.28CBC.29 >=20 > dm-crypt or other disk encryption programs use more complicated schemes= , > do we need to go there? Yep, that is another particularly good reason to deprecate qcow2's existing aes encryption and adopt an existing format that has got a proven good design like LUKS. 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 :|