From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36547) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V21H7-0005L6-1Z for qemu-devel@nongnu.org; Wed, 24 Jul 2013 11:46:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V21H5-0005cd-BA for qemu-devel@nongnu.org; Wed, 24 Jul 2013 11:46:48 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42693) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V21H5-0005cM-3N for qemu-devel@nongnu.org; Wed, 24 Jul 2013 11:46:47 -0400 Date: Wed, 24 Jul 2013 16:46:39 +0100 From: "Daniel P. Berrange" Message-ID: <20130724154639.GE30336@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> <20130724153304.GD30336@redhat.com> <51EFF55E.6070700@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <51EFF55E.6070700@redhat.com> 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:40:14PM +0200, Paolo Bonzini wrote: > Il 24/07/2013 17:33, Daniel P. Berrange ha scritto: > >>> 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? > > > > 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. > > Note that this is independent of LUKS vs. anything else. LUKS only > provides the key, you then have to implement encryption yourself. And > full implementation of all the cyphers and modes that LUKS supports > would be a lot of work. > > In fact, LUKS supports a cypher mode as weak as the current qcow2 mode > ("cbc-plain") and it even supports ECB. And dually, adding a more > robust cypher mode to the current qcow2 encryption would be trivial and > would protect against the watermarking attack (it would not fix the > problems with keys, of course, so I'm not suggesting to do it). True, implementing all the algorithms that the kernel supports for LUKS would be alot of work, and mostly a waste of time for the weak modes. So we'd probably want to be pragmatic about what we targetted, and pick a handful of common ciphers which are considered strong and commonly used by high quality disk encryption software. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|