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 haven't looked at qcow2 encryption in the past because fairly few people actually use it. One use-case I have heard about is qcow2 files over NFS. The network and the storage system should not see guest data. Only the host and the VM should see the data. A big win with LUKS is that you can change the passphrase without re-encrypting the data. Stefan