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

From: Paul Menzel <pm.debian@googlemail.com>
To: Milan Broz <mbroz@redhat.com>
Cc: dm-crypt@saout.de
Subject: Re: [dm-crypt] How can a passphrase be incorrect even after `luksHeaderBackup` and `luksHeaderRestore`?
Date: Fri, 5 Aug 2011 10:41:02 +0200	[thread overview]
Message-ID: <CAOOH3poMKtT0j_Uuuy9bmEepMgVwpmi5s-awqS5O8R19u34xHg@mail.gmail.com> (raw)
In-Reply-To: <4E3B5378.2070003@redhat.com>

2011/8/5 Milan Broz <mbroz@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@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@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@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@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@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@grml ~ # mount -o loop new-drive--dd-bs4M la
mount: unknown filesystem type 'crypto_LUKS'
32 root@grml ~ # losetup /dev/loop3 new-drive--dd-bs4M
root@grml ~ # cryptsetup isLuks /dev/loop3 /dev/loop3 # True because
on next line no error code in the beginning.

root@grml ~ # cryptsetup luksHeaderBackup /dev/loop3
--header-backup-file sda.header
root@grml ~ # losetup /dev/loop4 old-drive--dd-bs4M
root@grml ~ # cryptsetup isLuks /dev/loop4
root@grml ~ # cryptsetup luksHeaderBackup /dev/loop4
--header-backup-file sdb.header
root@grml ~ # md5sum *header
7b897c620776f549324810a8aeb9921e  sda.header
ce314509007b2c76eb85e7b89ee25da5  sdb.header
root@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@grml ~ # cryptsetup luksHeaderBackup /dev/loop3
--header-backup-file sda.header2
root@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