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

[Kevin Wolf <kwolf@redhat.com>]

Am 29.07.2013 um 13:21 hat Markus Armbruster geschrieben:
> Paolo Bonzini <pbonzini@redhat.com> writes:
> 
> > 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
> 
> 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".
> 
> Crypto should be done by trained professionals[*].
> 
> [...]
> 
> 
> [*] 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