qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v6 13/18] qcow2: add support for LUKS encryption


From: Alberto Garcia
Subject: Re: [Qemu-devel] [PATCH v6 13/18] qcow2: add support for LUKS encryption format
Date: Thu, 11 May 2017 16:44:56 +0200
User-agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (i586-pc-linux-gnu)

On Tue 25 Apr 2017 05:38:53 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 <address@hidden>

Reviewed-by: Alberto Garcia <address@hidden>

Berto



reply via email to

[Prev in Thread] Current Thread [Next in Thread]