Arno Wagner <arno@...> 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 _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
