From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60621) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V211a-0003vy-TI for qemu-devel@nongnu.org; Wed, 24 Jul 2013 11:30:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V211V-0000C8-Jv for qemu-devel@nongnu.org; Wed, 24 Jul 2013 11:30:46 -0400 Received: from mail-yh0-x230.google.com ([2607:f8b0:4002:c01::230]:46775) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V211V-0000Bo-Ed for qemu-devel@nongnu.org; Wed, 24 Jul 2013 11:30:41 -0400 Received: by mail-yh0-f48.google.com with SMTP id b20so170441yha.21 for ; Wed, 24 Jul 2013 08:30:41 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <51EFF30E.9060102@redhat.com> Date: Wed, 24 Jul 2013 17:30:22 +0200 From: Paolo Bonzini MIME-Version: 1.0 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> In-Reply-To: <20130723155741.GI2477@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 , =?UTF-8?B?QmVub8OudCBDYW5ldA==?= , qemu-devel@nongnu.org, stefanha@redhat.com, Stefan Hajnoczi 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ît Canet wrote: >>>>> 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 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 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 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 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 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. > > 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 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 attacks. For example, current qcow2 encryption is vulnerable to a watermarking attack. http://en.wikipedia.org/wiki/Disk_encryption_theory#Cipher-block_chaining_.28CBC.29 dm-crypt or other disk encryption programs use more complicated schemes, do we need to go there? Paolo