Re: Detached headers, multiple drives and UUIDs

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

 



On 04/10/2017 04:33 PM, 7heo wrote:
On Mon Apr 10 16:09:53 2017 GMT+0200, Ondrej Kozina wrote:
On 04/10/2017 03:45 PM, 7heo wrote:
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).

It depends. Old data is _not_ automatically re-written by luksFormat
operation during format operation. There may be old plain text data on
luks data device, unrelated to luks...

By that question I didn't mean to ask what the data drive would contain from previous usages; but what dm-crypt/LUKS related data it would contain. Since you answered a different interpretation of my question, I am unsure as to what the answer of my current question is.

So do the data-only devices contain any more LUKS/dm-crypt relevant information than the binary data itself?

No, cryptsetup doesn't store any metadata on data device if you use detached header scenario.



2. The UUID needs to match the header during drive opening only (after
that it is in RAM).

No, it's checked (header uuid must match active dm-crypt device) also
with different cryptsetup commands.

Ok so the header is continuously checked. I did not expect that, and expected all of it to be copied in memory until hibernation/shutdown. Thanks for the information.


3. It is therefore possible to change the UUID on the fly while
activating the disk, when putting the key in memory.

No you can't change UUID of active dm-crypt device without deactivating
it. It's device-mapper restriction and it has a good reason.

The idea was/is to change it while opening/activating it, not after.

No, you can't change uuid even during dm-crypt activation. The uuid has to match the one found in header.



4. The on-the-fly UUID can be computed using partially the detached
header UUID and a hash of the data drive being opened.

There's no connection between detached luks header and inactive (no
dm-crypt mapping active) separate data device, again on purpose.

I am not sure what you are answering to, the "on the fly UUID" was referring to the previous point, it does not make much sense without it.

Well in that case I truly don't understand the question. There's no connection between luks header and data device while being inactive or even while being activated. You may activate whatever data device if you supply correct passphrase for the header.

To follow on answer to Q1. there's data/information on data device that would link it to the detached header and vice versa.

For user the only indication he paired the right header with right data device is that the decrypted data (activated dm-crypt device) makes sense. iow user is able to mount fs because there's visible fs superblock and not 'garbage/noise'.

O.
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt



[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux