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...
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.
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.
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.
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.
Kind regards Ondrej _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
