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? > > > 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. > > > 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. > > > > > 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? > > I'd say use the walkthrough Milan outlined. Create X copies of the > original header and have different (generated) UUID on each of those. > > Having 2 or more devices with same UUID can lead only to problems. Don't > try to workaround it. I am pretty sure at this point that we are failing to understand each other. What I meant is to ask wether or not it was a good idea (let alone possible) to automatize the creation of the headers Milan advised me to create (and wipe them afterwards). I am very well aware of the problems that a non-unique UUID would cause; that is the main reason for my first email. > > Kind regards > Ondrej Thanks for your time, Theo. _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
