Hello Milan,
Please tell me if my current assumptions are correct:
1. Any non-open LUKS data-only drive contains 100% random looking data
(i.e. No metadata at all).
2. The UUID needs to match the header during drive opening only (after
that it is in RAM).
3. It is therefore possible to change the UUID on the fly while
activating the disk, when putting the key in memory.
4. The on-the-fly UUID can be computed using partially the detached
header UUID and a hash of the data drive being opened.
Or is any of this wrong? If it isn't possible, I could see a wrapper
around cryptsetup copying the headers around in a ramfs while doing the
aforementioned substitution. Or would that be impossible?
Many thanks,
Theo.
On Mon Apr 10 15:25:31 2017 GMT+0200, Milan Broz wrote:
On 04/10/2017 03:07 PM, 7heo wrote:
> Hello all,
>
> I have a question regarding the deported headers in LUKS, and how it
> can be used to simplify the setup of RAID over LUKS:
>
> The current way to automatically unlock all the drives used in a Raid
> array seems to be to add the same key to all the drives in the
> array.
>
> However that doesn't work with detached headers for obvious reasons.
> The detached headers can apparently be used on any number of
> devices/files at the same time, with one problem: they all have the
> same UUID. I tried using the --uuid flag with luksOpen without
> success.
You cannot change UUID for activated LUKS device, UUID must match the header
(otherwise libcryptsetup cannot handle many functions).
But you can simply duplicate detached header and then change UUID
inside that duplicated header (use luksUUID --uuid to do that).
(IOW every device will have own header that differs only in UUID.)
(In future there will be much simpler way to do that using kernel keyring
but that will be part of LUKS2.)
Milan
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
