Am 29.07.2013 um 13:21 hat Markus Armbruster geschrieben: > Paolo Bonzini <pbonz...@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
