On 11/20/2014 10:33 PM, Dale R. Worley wrote: >> From: Drake Wilson <drake@xxxxxxxxxxxxxx> > >> 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 -- To unsubscribe from this list: send the line "unsubscribe util-linux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
