From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60598) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V3pxm-0006yF-S0 for qemu-devel@nongnu.org; Mon, 29 Jul 2013 12:06:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V3pxg-0004qG-Tx for qemu-devel@nongnu.org; Mon, 29 Jul 2013 12:06:22 -0400 Received: from nodalink.pck.nerim.net ([62.212.105.220]:50774 helo=paradis.irqsave.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V3pxg-0004q1-AX for qemu-devel@nongnu.org; Mon, 29 Jul 2013 12:06:16 -0400 Date: Mon, 29 Jul 2013 18:07:52 +0200 From: =?iso-8859-1?Q?Beno=EEt?= Canet Message-ID: <20130729160752.GB4550@irqsave.net> 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> <20130729113235.GN28588@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20130729113235.GN28588@redhat.com> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] QCOW2 cryptography and secure key handling List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: Kevin Wolf , =?iso-8859-1?Q?Beno=EEt?= Canet , Stefan Hajnoczi , qemu-devel@nongnu.org, Markus Armbruster , stefanha@redhat.com, Paolo Bonzini Le Monday 29 Jul 2013 =E0 12:32:35 (+0100), Daniel P. Berrange a =E9crit = : > 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=EEt Canet wrote= : > > > >>>>>> More generally, QCow2's current encryption support is woeful= ly inadequate > > > >>>>>> from a design POV. If we wanted better encryption built-in t= o QEMU it is > > > >>>>>> best to just deprecate the current encryption support and de= fine a new > > > >>>>>> qcow2 extension based around something like the LUKS data fo= rmat. Using > > > >>>>>> the LUKS data format precisely would be good from a data por= tability > > > >>>>>> POV, since then you can easily switch your images between LU= KS encrypted > > > >>>>>> block device & qcow2-with-luks image file, without needing t= o 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 k= eys, > > > >>>>> 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 tak= e 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 som= e people > > > >>> have repeatedly been arguing that it still results in bad crypt= o. 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 da= ta. > > > >> Thus a weak passphrase leads to weak data encryption. With the L= UKS > > > >> format, the passphrase is only used to unlock the master key, wh= ich > > > >> is cryptographically strong. LUKS applies multiple rounds of has= hing > > > >> to the user passphrase based on the speed of the machine CPUs, t= o > > > >> make it less practical to brute force weak user passphrases and = thus > > > >> recover the master key. > > > > > > > > Another reason that QCow2 is bad is that disk encryption is Compl= icated. > > > > 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 watermar= king > > > > attack. > > > > http://en.wikipedia.org/wiki/Disk_encryption_theory#Cipher-block_= chaining_.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 y= ou > > add LUKS-like features? You still use them in a different context, an= d > > that may or may not break it. I can't really say. >=20 > 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 Re= d > Hat has people on its security team who we might be able to get to revi= ew > any proposals in this area, if we wanted further crypto advise. If we w= ent > with an approach of incorporating LUKS, then we should also connect wit= h > the dm-crypt maintainers / LUKS designers to ask them to review what w= e're > proposing to do. http://www.spinics.net/lists/dm-crypt/msg05277.html Best regards Beno=EEt >=20 > Regards, > Daniel > --=20 > |: http://berrange.com -o- http://www.flickr.com/photos/dberran= ge/ :| > |: http://libvirt.org -o- http://virt-manager.= org :| > |: http://autobuild.org -o- http://search.cpan.org/~danbe= rr/ :| > |: http://entangle-photo.org -o- http://live.gnome.org/gtk-= vnc :| >=20