[dm-crypt] How can a passphrase be incorrect even after `luksHeaderBackup` and `luksHeaderRestore`?

Paul Menzel pm.debian at googlemail.com
Fri Aug 5 10:41:02 CEST 2011


2011/8/5 Milan Broz <mbroz at redhat.com>:
> On 08/05/2011 01:18 AM, Paul Menzel wrote:
>> % sudo md5sum /tmp/*header
>> 7b897c620776f549324810a8aeb9921e  /tmp/sda2.header
>> 7b897c620776f549324810a8aeb9921e  /tmp/sda.header
>> ce314509007b2c76eb85e7b89ee25da5  /tmp/sdb.header
>> ------- 8< --- entered commands --- >8 -------
>>
>> I would have assumed that all files are identical, i. e. they have the
>> same hash.
>
> It should be the same.
> (But there is gap between header and keyslot which is explicitly wiped
> during backup. But from the commands you run it should be the same now.)
>
> On which binary offsets it differs?

Do you mean the value of Payload offset in the output of `cryptsetup
luksDump /dev/sda2`? Both have the value 2048.

> Can you try the same exercise but running it through loop device?
>
> (dd e.g. 4M from both sd[ab] disks, map it to loop devices and run the same
> commands - luksHeaderBackup/Restore.

------- 8< --- entered commands --- >8 -------
root at grml ~ # dd bs=1024 count=4096 if=/dev/sda2 of=new-drive--dd-bs4M
4096+0 records in
4096+0 records out
4194304 bytes (4.2 MB) copied, 0.563301 s, 7.4 MB/s
root at grml ~ # dd bs=1024 count=4096 if=/dev/sdb2 of=old-drive--dd-bs4M
4096+0 records in
4096+0 records out
4194304 bytes (4.2 MB) copied, 0.121917 s, 34.4 MB/s
root at grml ~ # dd bs=1024 count=1024 if=/dev/sda2 of=new-drive--dd-bs1M
1024+0 records in
1024+0 records out
1048576 bytes (1.0 MB) copied, 0.0256151 s, 40.9 MB/s
root at grml ~ # dd bs=1024 count=1024 if=/dev/sdb2 of=old-drive--dd-bs1M
1024+0 records in
1024+0 records out
1048576 bytes (1.0 MB) copied, 0.0223845 s, 46.8 MB/s
root at grml ~ # md5sum *drive*
62ca46f7ed57f7ef673f58547fd438c6  new-drive--dd-bs1M
9d30117b0d9d3e57d6269916123ed9f2  new-drive--dd-bs4M
11faaf01449e87f40378945392819c09  old-drive--dd-bs1M
bd7aa8cc17a59cd74f2fc30a154cb823  old-drive--dd-bs4M

# no filesystem on there, so error. Error code 32 on next line in ZSH.
root at grml ~ # mount -o loop new-drive--dd-bs4M la
mount: unknown filesystem type 'crypto_LUKS'
32 root at grml ~ # losetup /dev/loop3 new-drive--dd-bs4M
root at grml ~ # cryptsetup isLuks /dev/loop3 /dev/loop3 # True because
on next line no error code in the beginning.

root at grml ~ # cryptsetup luksHeaderBackup /dev/loop3
--header-backup-file sda.header
root at grml ~ # losetup /dev/loop4 old-drive--dd-bs4M
root at grml ~ # cryptsetup isLuks /dev/loop4
root at grml ~ # cryptsetup luksHeaderBackup /dev/loop4
--header-backup-file sdb.header
root at grml ~ # md5sum *header
7b897c620776f549324810a8aeb9921e  sda.header
ce314509007b2c76eb85e7b89ee25da5  sdb.header
root at grml ~ # cryptsetup luksHeaderRestore /dev/loop3
--header-backup-file sdb.header

WARNING!
========
Device /dev/loop3 already contains LUKS header. Replacing header will
destroy existing keyslots.

Are you sure? (Type uppercase yes): YES
root at grml ~ # cryptsetup luksHeaderBackup /dev/loop3
--header-backup-file sda.header2
root at grml ~ # md5sum *header*
7b897c620776f549324810a8aeb9921e  sda.header
ce314509007b2c76eb85e7b89ee25da5  sda.header2
ce314509007b2c76eb85e7b89ee25da5  sdb.header
------- 8< --- entered commands --- >8 -------

> Do you see the same problem?

No, as from the output above, I do not see the same problem. What
could be the reason for this difference in behaviour?


Thanks,

Paul


More information about the dm-crypt mailing list