From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39194) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V3lh8-0005Xc-LD for qemu-devel@nongnu.org; Mon, 29 Jul 2013 07:32:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V3lh3-0004RX-HX for qemu-devel@nongnu.org; Mon, 29 Jul 2013 07:32:54 -0400 Received: from mx1.redhat.com ([209.132.183.28]:22069) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V3lh3-0004RQ-AU for qemu-devel@nongnu.org; Mon, 29 Jul 2013 07:32:49 -0400 Date: Mon, 29 Jul 2013 12:32:35 +0100 From: "Daniel P. Berrange" Message-ID: <20130729113235.GN28588@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> <87vc3t8vce.fsf@blackfin.pond.sub.org> <20130729112524.GA10467@dhcp-200-207.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20130729112524.GA10467@dhcp-200-207.str.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: Kevin Wolf Cc: =?utf-8?Q?Beno=C3=AEt?= Canet , Stefan Hajnoczi , Markus Armbruster , qemu-devel@nongnu.org, stefanha@redhat.com, Paolo Bonzini On Mon, Jul 29, 2013 at 01:25:24PM +0200, Kevin Wolf wrote: > Am 29.07.2013 um 13:21 hat Markus Armbruster geschrieben: > > Paolo Bonzini writes: > >=20 > > > 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 wrot= e: > > >>>>>> 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 defi= ne a new > > >>>>>> qcow2 extension based around something like the LUKS data form= at. Using > > >>>>>> the LUKS data format precisely would be good from a data porta= bility > > >>>>>> 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 t= o > > >>>>> understand the > > >>>>> potentials benefits (stronger encryption key, multiple user key= s, > > >>>>> possibility to > > >>>>> change users keys). > > >>>>> > > >>>>> Kevin & Stefan: What do you think about implementing LUKS in QC= OW2 ? > > >>>> > > >>>> 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. > > >>=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 LUK= S > > >> format, the passphrase is only used to unlock the master key, whic= h > > >> is cryptographically strong. LUKS applies multiple rounds of hashi= ng > > >> to the user passphrase based on the speed of the machine CPUs, to > > >> make it less practical to brute force weak user passphrases and th= us > > >> recover the master key. > > > > > > Another reason that QCow2 is bad is that disk encryption is Complic= ated. > > > 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= attacks. > > > > > > For example, current qcow2 encryption is vulnerable to a watermarki= ng > > > attack. > > > http://en.wikipedia.org/wiki/Disk_encryption_theory#Cipher-block_ch= aining_.28CBC.29 > >=20 > > Fine example of why the "we use a standard, strong cypher (AES), > > therefore our crypto must be good" argument is about as convincing as= "I > > built this sandcastle from the finest quartz sand, so it must be > > strong". > >=20 > > Crypto should be done by trained professionals[*]. > >=20 > > [...] > >=20 > >=20 > > [*] I studied crypto deeply enough to know I'm not. >=20 > The point is, how do you know that you end up with good crypto when you > add LUKS-like features? You still use them in a different context, and > that may or may not break it. I can't really say. If we're not sufficiently confident in what we're doing, then we ought to find suitable people to advise us / review what we'd propose. I know Red Hat has people on its security team who we might be able to get to review any proposals in this area, if we wanted further crypto advise. If we wen= t with an approach of incorporating LUKS, then we should also connect with the dm-crypt maintainers / LUKS designers to ask them to review what we'= re proposing to do. 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 :|