lacks superblock backup about cryptsetup HOT 5 CLOSED

Backup of LUKS header is easy, something like that (not much tested:-):

DEVICE=/dev/sdg
BACKUP_FILE=tst
SECTORS=$(cryptsetup luksDump $DEVICE | grep 'Payload offset' | sed 's/^.*\W//')

dd if=$DEVICE of=$BACKUP_FILE bs=512 count=$SECTORS

luksRestore is simple dd file back.

Maybe is internal luksBackup/Restore (to provided filespec) enough?

Hey,

I know that it's that simple to backup the luks header, but I guess that people 
would
be more satisfied with implemented luksBackup/luksRestore actions in cryptsetup.

Maybe the luksBackup action could prompt for confirmation after printing a big 
fat
warning that dumping the luks header to a filesystem is unsecure and that 
people need
to be really careful with the header backup.
(i.e. best to write it directly to a usb device, and if it's burned to 
cd/dvd/...
then at least /tmp should be encrypted)

In another bugreport in debian (bugs.debian.org/432150) we got a request for
something like a luksRepair function, which fixes broken luks headers (for sure
that's only possible if both the master key and at least one slot are still 
available).

greetings,
 jonas

PS: thanks for taking care of cryptsetup, i've the impression that you do a 
really
good job :-)

I added luksHeaderBackup and luksHeaderRestore commands.
(if just stores header + keyslot are, so it is compatible with dd above)

Backup also wipes unused area between header and keyslot area, so 
backup->restore can
be used for basic repair for LUKS header including e.g. old swap signature.
(Alsready fixed problem, but old header need not-too-user-friendly hack with dd 
to
fix this.)

I added some warning to man page about possible security problems... If you have
better formulation, please send a patch:-)

LUKS1 will never support multiple headers on disk - it will need new header 
structure
(-> LUKS2 maybe) and proper handling of redundant metadata. (We solved similar
problems in lvm2 and maintaining multiple metadata areas on disk _properly_  is 
not
so easy as it seems...)

Mmmm, will be possible to convert LUKS1 to the future LUKS2? I mean without 
having to
move all the date, redone the dm-crpyt and dump the data back again?

> will be possible to convert LUKS1 to the future LUKS2?

I have no answer to that question, LUKS2 do not exist yet:-) But if there is no
technical reason, there should be some automatic conversion, (but 
Backup/Restore is
intended for using the same format)

Convert can use backup->retrieve master key->format with LUKS 2 using the same
parameters + the same master key, this way no shuffle of data is needed.
Anyway, you cannot convert automatically all keyslots without entering all 
passphrases.