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. So what can we take from LUKS, how would it be integrated in qcow2 and what will the final result be like then? For example, currently qcow2 doesn't encrypt metadata. Is this a problem? If metadata is encrypted, you have some blocks whose content is pretty predictable. Does this hurt? I guess if you want to plausibly claim that some new code does better, some questions like these have to be answered. Kevin
