[dm-crypt] The future of disk encryption with LUKS2

f-dm-c at media.mit.edu f-dm-c at media.mit.edu
Mon Feb 8 21:11:27 CET 2016


[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.)


More information about the dm-crypt mailing list