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

[Kevin Wolf]

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