[Top][All Lists]

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

Re: [Qemu-block] [PATCH v7 12/20] qcow2: extend specification to cover L

From: Eric Blake
Subject: Re: [Qemu-block] [PATCH v7 12/20] qcow2: extend specification to cover LUKS encryption
Date: Thu, 25 May 2017 14:39:56 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0

On 05/25/2017 11:38 AM, Daniel P. Berrange wrote:
> Update the qcow2 specification to describe how the LUKS header is
> placed inside a qcow2 file, when using LUKS encryption for the
> qcow2 payload instead of the legacy AES-CBC encryption
> Reviewed-by: Alberto Garcia <address@hidden>
> Reviewed-by: Max Reitz <address@hidden>
> Signed-off-by: Daniel P. Berrange <address@hidden>
> ---
>  docs/specs/qcow2.txt | 96 
> ++++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 96 insertions(+)

> +
> +The first 592 bytes of the header clusters will contain the LUKS
> +partition header. This is then followed by the key material data areas.
> +The size of the key material data areas is determined by the number of
> +stripes in the key slot and key size. Refer to the LUKS format
> +specification ('docs/on-disk-format.pdf' in the cryptsetup source
> +package) for details of the LUKS partition header format.
> +
> +In the LUKS partition header, the "payload-offset" field will be
> +calculated as normal for the LUKS spec. ie the size of the LUKS
> +header, plus key material regions, plus padding, relative to the
> +start of the LUKS header. Its value is never used in the context
> +of qcow2, however, since the qcow2 file format itself defines where
> +the real payload offset is.

Is it possible/valid for the LUKS payload-offset field to NOT be
qcow2-cluster-aligned?  (I'm guessing yes, for example, if we have 2M
clusters; and that we don't care, because you documented that we don't
actually use that offset).  Is it worth documenting this?

> +== Data encryption ==
> +
> +When an encryption method is requested in the header, the image payload
> +data must be encrypted/decrypted on every write/read. The image headers
> +and metadata is never encrypted.


> +
> +The algorithms used for encryption vary depending on the method
> +
> + - AES:
> +
> +   The AES cipher, in CBC mode, with 256 bit keys.
> +
> +   Initialization vectors generated using plain64 method, with
> +   the virtual disk sector as the input tweak.

Worth documenting that implementations should avoid creating new images
with this encryption (ie. make it officially part of the spec that this
is not recommended, but merely documented for back-compat data
liberation purposes)?

Reviewed-by: Eric Blake <address@hidden>

Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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