Humm, well, I think a backup copy of the header would be right at the
end. Question remains, keep the ordering of the primary header, or let
it grow down like a stack, i.e. last sector has the luks signature, key
material in front of that.
Anyhow, as dd itself does not support negative values (for offsets), you
could still easily use blockdev and substract a secure value of sectors
from that and pass it to dd in case you do not have cryptsetup at hand.
If that takes too much time, a single line script can save you some time.
Regards
-Sven
Am 08.02.2016 um 21:11 schrieb f-dm-c@xxxxxxxxxxxxx:
[This is in a separate message because it could be a distraction.
I'm just tossing this stuff as food for thought, but don't want
to derail.]
Given all the complexity about "how do we do this atomically,"
there's also the really simple idea of just writing several copies
of the header, perhaps one right after the other, and just -voting-.
(The ITS operating system, which ran on PDP-10's back in the 70's
and 80's, did precisely this with its directories---it replicated
its directory structure onto every disk pack in parallel, and when
the machine came up, it simply did a majority vote amongst the packs.)
This gives LUKS lots of redundancy and a mechanism to pick the right
header that's really easy to analyze for correctness. I have nothing
against generation counts---they would help win a tie from an
unfortunate corruption that leads to an even number of survivors
---but voting may help with the whole "how do we know when disks do
their writes" issue by encouraging lots of redundant copies.
P.S. My other worry with "header at the end" concerns deliberate
overwrite. If I have a LUKS container and I want to be absolutely
sure that I've wiped all keys before I discard the device,* writing
a few meg, or even a gig, to the front of it guarantees this. With a
header at the end, I need to be able to figure out where that header
is. (I can't count on always having the luxury of using LUKS itself
to wipe every keyslot when discarding a disk.) Sure, I can do the
math and issue the correct dd into the container at the right offset,
but it encourages mistakes.
* (I can think of several scenarios whereby someone may have had
access, authorized or not, to a pasphrase, so I want to ensure
that such knowledge can't do them any good once I let the disk
out of my physical possession.)
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
