Re: [Qemu-devel] Volume key in qcow3?

[Frediano Ziglio]

2011/7/28 Kevin Wolf <address@hidden>:
> Am 28.07.2011 10:05, schrieb Frediano Ziglio:
>> Hi,
>>   I noted that AES encryption using qcow2 just use the password given
>> as as key (and also truncating it to 16 bytes == 128 bits).
>> This is prone to brute force attacks and is not also easy to change
>> password (you have to decrypt and encrypt again the entire image).
>> LUKS and EncFS use another way. They generate a random key (the
>> "volume key") then use the password you give to encrypt N times (where
>> N is decided by security level or automatically based on time to
>> decrypt the volume key. To change the password just give the old one,
>> get the volume key and encrypt again using the new one. LUKS support
>> also multiple "slots" to allow multiple password and even using an
>> external key file.
>> Obviously this require an additional extension to qcow2 so I think it
>> require a new qcow3 format.
>
> Yes, once we have qcow3, adding things like this should be easy enough.
> I think the idea makes sense.
>
> Another thing to consider with encryption is that we don't encrypt
> metadata currently. I'm not entirely sure if this is a good or a bad
> thing. Metadata is relatively predictable and I think that might hurt
> the encryption? Though I'm really not an expert in this area.
>
> Kevin
>

I don't think this is a big issue, usually sensitive data is not in
knowing which clusters are allocated or in which sequence (perhaps
looking at allocation strategy you can detect operating system and
filesystem type), snapshot ids and descriptions are IMO more sensible.

Do anybody though that qcow2 can support data-deduplication using
refcounts? Well, in this case this is not possible with encrypted
data.

Frediano