[dm-crypt] No key available for this passphrase

Sebastian r4p.t0x at googlemail.com
Sun Jan 27 09:42:19 CET 2013


Arno Wagner <arno at ...> writes:

> 
> Second lesson: Flash-keys are unsuitable for long-term 
> storage (has to tell that one customer already that wanted
> to store an important master key that way. Fortunately they
> asked us first...)
> 
> Here is a way for reliable long-term storage of small anounts
> of data:
> Print it with a laser-printer as OCR-A/B on good paper.
> Adding per-line checksums might be a good idea.
> Or print it as a sequence of QR codes - checksums and
> error correction already included.
> 
> The other oprion is to store it in multiple locations and 
> check the date regularly.
> 
> Arno


I like the idea of printing it as QR-code, never thought of using QR-Codes for
backups ;)
I will consider it for the ne setup!
Should be also usable for gpg-keys...


Another idea I had yesterday evening:
I'm using a small ramdisk on my normal PC for playing minecraft - it meanwhile
has a rather blown-up code and writes frequently to disk, causing slower
machines to "hickup" every ~3 seconds. increasing read/write speed by using a
ramdisk eliminates these symptoms.
I use a small shellscript for initiating the ramdisk, cloning the data and
syncing it. 

So, why not use such a mechanism (to ramdisk or normal disk) for backing up the
header on boot time, and on shutdown comparing the backup with the current
header. If equal -> everything is fine. If not - prompt either to restore it or
leave it (when adde a new key e.g.), maybe even with a "diff"-output.

It won't replace the real backup(s), but will give a little more failure
tolerance plus a warning on shutdown IF anything went wrong with the header, so
e.g. when on travel far away from backups you could restore the header.
As the backup won't contain anything else than the header already does, I don't
think it adds vulnerability to the system. If anyone gets access to the running
system he could gain access to the header (and the key in the memory!) anyways. 

I think i will give this a try on the new setup on my Notebook. I can post the
script here at the mailing list (it will be only a shellscript - my C has never
evolved far over "hello world" ;) ), but a function like this or any other
mechanism of header-protection would be nice to see as standard for LUKS.
Especially because the first keyslot is so likely to be corrupted by partition
managers (should be aroud the offset of keyslot 0 where they start to dump their
data?).


Sebastian



More information about the dm-crypt mailing list