Re: LUKS partition types, redux

[Milan Broz <gmazyland@gmail.com>]

On 11/20/2014 10:33 PM, Dale R. Worley wrote:
>> From: Drake Wilson <drake@dasyatidae.net>
> 
>> I might support an extension
>> proposal to allow (but not require) a type for the underlying volume to
>> be added as part of the _LUKS_ header, therefore (probably using a GPT
>> type just for convenience).
> 
> That sounds like a better proposal to me.  But I have no idea whether
> LUKS can support such an extension.

If I understand it correctly, you want to duplicate some UUID stored
in LUKS container payload to LUKS header?

LUKS will not support such extension. For two reasons:

- there is a clear layer separation, LUKS handle block layer encryption,
treating container data as a block device. It doesn't care about any
signatures or whatever is contained in data.
This information can be stored elsewhere (UUID in fstab of underlying device,
for example) but not in the LUKS header.

- for security reasons: if you add visible UUID of data inside container,
now you have definitely at least part of plaintext/ciphertext pair
available for attacker (UUID is stored on fixed offset).

Not that it makes possible ciphertext modification attacks to devices without
integrity protection much worse... but use this concept as a design decision
in a security tool would be just ridiculous.

Milan