[dm-crypt] The future of disk encryption with LUKS2
sven at whgl.uni-frankfurt.de
Mon Feb 8 21:35:21 CET 2016
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.
Am 08.02.2016 um 21:11 schrieb f-dm-c at media.mit.edu:
> [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 at saout.de
More information about the dm-crypt