From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IzWVOuJC80U6 for ; Fri, 5 Aug 2011 10:41:02 +0200 (CEST) Received: from mail-fx0-f50.google.com (mail-fx0-f50.google.com [209.85.161.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Fri, 5 Aug 2011 10:41:02 +0200 (CEST) Received: by fxh2 with SMTP id 2so2362816fxh.37 for ; Fri, 05 Aug 2011 01:41:02 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4E3B5378.2070003@redhat.com> References: <4E3B5378.2070003@redhat.com> Date: Fri, 5 Aug 2011 10:41:02 +0200 Message-ID: From: Paul Menzel Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [dm-crypt] How can a passphrase be incorrect even after `luksHeaderBackup` and `luksHeaderRestore`? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Milan Broz Cc: dm-crypt@saout.de 2011/8/5 Milan Broz : > On 08/05/2011 01:18 AM, Paul Menzel wrote: >> % sudo md5sum /tmp/*header >> 7b897c620776f549324810a8aeb9921e =C2=A0/tmp/sda2.header >> 7b897c620776f549324810a8aeb9921e =C2=A0/tmp/sda.header >> ce314509007b2c76eb85e7b89ee25da5 =C2=A0/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 sa= me > commands - luksHeaderBackup/Restore. ------- 8< --- entered commands --- >8 ------- root@grml ~ # dd bs=3D1024 count=3D4096 if=3D/dev/sda2 of=3Dnew-drive--dd-b= s4M 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=3D1024 count=3D4096 if=3D/dev/sdb2 of=3Dold-drive--dd-b= s4M 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=3D1024 count=3D1024 if=3D/dev/sda2 of=3Dnew-drive--dd-b= s1M 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=3D1024 count=3D1024 if=3D/dev/sdb2 of=3Dold-drive--dd-b= s1M 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! =3D=3D=3D=3D=3D=3D=3D=3D 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