Le Monday 29 Jul 2013 à 12:32:35 (+0100), Daniel P. Berrange a écrit : > On Mon, Jul 29, 2013 at 01:25:24PM +0200, Kevin Wolf wrote: > > 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. > > If we're not sufficiently confident in what we're doing, then we ought to > find suitable people to advise us / review what we'd propose. I know Red > Hat has people on its security team who we might be able to get to review > any proposals in this area, if we wanted further crypto advise. If we went > with an approach of incorporating LUKS, then we should also connect with > the dm-crypt maintainers / LUKS designers to ask them to review what we're > proposing to do.
http://www.spinics.net/lists/dm-crypt/msg05277.html Best regards Benoît > > Regards, > 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 :| >
