Re: [Qemu-devel] QCOW2 cryptography and secure key handling

["Daniel P. Berrange" <berrange@redhat.com>]

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 :|