From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37033) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V3laF-0001H6-6a for qemu-devel@nongnu.org; Mon, 29 Jul 2013 07:25:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V3la4-0002RT-I9 for qemu-devel@nongnu.org; Mon, 29 Jul 2013 07:25:47 -0400 Received: from mx1.redhat.com ([209.132.183.28]:2264) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V3la4-0002R9-0L for qemu-devel@nongnu.org; Mon, 29 Jul 2013 07:25:36 -0400 Date: Mon, 29 Jul 2013 13:25:24 +0200 From: Kevin Wolf Message-ID: <20130729112524.GA10467@dhcp-200-207.str.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> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <87vc3t8vce.fsf@blackfin.pond.sub.org> 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: Markus Armbruster Cc: =?iso-8859-1?Q?Beno=EEt?= Canet , Stefan Hajnoczi , qemu-devel@nongnu.org, stefanha@redhat.com, Paolo Bonzini 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 woefully i= nadequate > >>>>>> from a design POV. If we wanted better encryption built-in to QE= MU 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 portabi= lity > >>>>>> POV, since then you can easily switch your images between LUKS e= ncrypted > >>>>>> 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 QCOW= 2 ? > >>>> > >>>> Using standard or proven approachs in crypto is a good thing. > >>> > >>> I think the question is how much of a standard approach you take an= d > >>> 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 pe= ople > >>> have repeatedly been arguing that it still results in bad crypto. A= re > >>> 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. > > > > Another reason that QCow2 is bad is that disk encryption is Complicat= ed. > > 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 a= ttacks. > > > > For example, current qcow2 encryption is vulnerable to a watermarking > > attack. > > http://en.wikipedia.org/wiki/Disk_encryption_theory#Cipher-block_chai= ning_.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. 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. Kevin