[dm-crypt] yet another "lost my partition" message
jonas at freesources.org
Fri Apr 15 21:37:52 CEST 2011
On 15/04/2011 Arno Wagner wrote:
> On Fri, Apr 15, 2011 at 03:52:34PM +0200, Cristian KLEIN wrote:
> > I assume there is no way to recover the original file system. Ubuntu has
> > most likely overwritten the LUKS header where the pretious salt is being
> > stored. The unencrypted disk most likely looks like random data now.
> > According to the FAQ , you can still resort to the dm-crypt
> > mailing-list to get over the five stages of grief.
> This may sound like sarcasm, but it is not. I wrote that and I
> realize the pain is real. This passage however serves a dual
> purpose and the second one is to warn people.
> > A posteriori, I cannot help wonder why such pretious information isn't
> > kept redundantly.
> The FAQ discusses this. It is a design-choice as keeping the
> header redundantly lowers security significantly. There is
> really no way to keep a backup header without making the
> anti-forensic measures ineffective.
can you please elaborate on that? why not consider the following:?
luksFormat could choose a random sector at the second half of the
to-be-encrypted device, save the sector number in the primary header,
and store a backup of the primary header at this place.
obviously, all commands that write to the LUKS header would need to
write to primary and backup header in that case.
in case that one accidentially overwrites the primary header (which
is easily done as many device tools write to the first sectors of a
device), you still may grep the device for 'LUKS' in order to find the
backup header. that even would work in most cases if the device is
luksFormated again: the likeliness that luksFormat chooses the same
random sector for its backup header both times, is not very high, and
decreases with the size of device.
as all luks commands write to both primary and backup header, shredding
the device would still be easy enough with luksKillSlot/luksRemoveKey.
nly thing that wouldn't work anymore, is overwriting the first few MB
of the device.
but then, it could be configurable by commandline whether luksFormat
creates a backup header at all, and everybody would be happy, no?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: Digital signature
More information about the dm-crypt