On Fri 23 Jun 2017 06:24:12 PM CEST, Daniel P. Berrange wrote: > This adds support for using LUKS as an encryption format > with the qcow2 file, using the new encrypt.format parameter > to request "luks" format. e.g. > > # qemu-img create --object secret,data=123456,id=sec0 \ > -f qcow2 -o encrypt.format=luks,encrypt.key-secret=sec0 \ > test.qcow2 10G > > The legacy "encryption=on" parameter still results in > creation of the old qcow2 AES format (and is equivalent > to the new 'encryption-format=aes'). e.g. the following are > equivalent: > > # qemu-img create --object secret,data=123456,id=sec0 \ > -f qcow2 -o encryption=on,encrypt.key-secret=sec0 \ > test.qcow2 10G > > # qemu-img create --object secret,data=123456,id=sec0 \ > -f qcow2 -o encryption-format=aes,encrypt.key-secret=sec0 \ > test.qcow2 10G > > With the LUKS format it is necessary to store the LUKS > partition header and key material in the QCow2 file. This > data can be many MB in size, so cannot go into the QCow2 > header region directly. Thus the spec defines a FDE > (Full Disk Encryption) header extension that specifies > the offset of a set of clusters to hold the FDE headers, > as well as the length of that region. The LUKS header is > thus stored in these extra allocated clusters before the > main image payload. > > Aside from all the cryptographic differences implied by > use of the LUKS format, there is one further key difference > between the use of legacy AES and LUKS encryption in qcow2. > For LUKS, the initialiazation vectors are generated using > the host physical sector as the input, rather than the > guest virtual sector. This guarantees unique initialization > vectors for all sectors when qcow2 internal snapshots are > used, thus giving stronger protection against watermarking > attacks. > > Signed-off-by: Daniel P. Berrange <berra...@redhat.com>
Reviewed-by: Alberto Garcia <be...@igalia.com> Berto
