* [dm-crypt] Anyone know why I can't access my volumes?
@ 2019-10-20 21:53 Philipp Rösch
2019-10-21 7:50 ` Michael Kjörling
0 siblings, 1 reply; 15+ messages in thread
From: Philipp Rösch @ 2019-10-20 21:53 UTC (permalink / raw)
To: dm-crypt
[-- Attachment #1: Type: text/plain, Size: 12687 bytes --]
Hi guys, I cannot for the life of me understand why I can't access my volumes. I tried everything.
I installed Arch Linux about a year ago with LUKS on LVM. After an update and reboot I can no longer access the volumes: "No key available with this passphrase."
-I have the correct passphrase
-Passphrase consists of only the first 128 ASCII
-Double checked the keyboard layout, tried a key file
-luksDump looks good to me
-chk_luks_keyslots looks good to me
-Tried with cryptsetup 2.0.5-1 and 2.2.1-1
-Tried Kernel 4.18.16 and most recent Arch Kernel (don't know the exact version)
-Toshiba SSD (SMART looks good, a year old laptop)
I welcome any idea or suggestion.
-- vgdisplay
--- Volume group ---
VG Name vg0
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 3
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 2
Open LV 0
Max PV 0
Cur PV 1
Act PV 1
VG Size 476.20 GiB
PE Size 4.00 MiB
Total PE 121908
Alloc PE / Size 121908 / 476.20 GiB
Free PE / Size 0 / 0
VG UUID 0ejFtO-AV4B-3C81-iHAQ-GKjQ-XHY7-l2BGJ7
-- lvdisplay
--- Logical volume ---
LV Path /dev/vg0/root
LV Name root
VG Name vg0
LV UUID IX7ERD-BVsI-m7kz-urJt-101W-jc5i-m4sut9
LV Write Access read/write
LV Creation host, time archiso, 2018-11-19 19:29:15 +0000
LV Status available
# open 0
LV Size 20.00 GiB
Current LE 5120
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 254:0
--- Logical volume ---
LV Path /dev/vg0/home
LV Name home
VG Name vg0
LV UUID Q1JKT2-U4ar-32Vd-V2Vr-2ZSP-1J0z-lwFEOi
LV Write Access read/write
LV Creation host, time archiso, 2018-11-19 19:29:48 +0000
LV Status available
# open 0
LV Size 456.20 GiB
Current LE 116788
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 254:1
-- ROOT
LUKS header information for /dev/vg0/root
Version: 1
Cipher name: aes
Cipher mode: xts-plain64
Hash spec: sha256
Payload offset: 4096
MK bits: 512
MK digest: a7 de d2 02 b1 d5 ed 2c 52 c2 d2 bc c5 65 a2 4a a9 d3 52 df
MK salt: af 2b 8d 00 87 88 b7 28 ef a0 9e 68 19 53 bd cc
46 a3 1d e2 d0 0f e0 32 94 0d c3 46 7e d5 ef 91
MK iterations: 120470
UUID: cdca293e-b5f7-4686-8723-51bfa910b44a
Key Slot 0: ENABLED
Iterations: 1949026
Salt: 1e 0a c5 72 85 9a 95 e7 ba 7b d2 98 4d b3 83 00
d1 07 93 a9 42 44 11 2c a3 4b f5 4c e5 b1 82 4b
Key material offset: 8
AF stripes: 4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED
00000000 4c 55 4b 53 ba be 00 01 61 65 73 00 00 00 00 00 |LUKS....aes.....|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000020 00 00 00 00 00 00 00 00 78 74 73 2d 70 6c 61 69 |........xts-plai|
00000030 6e 36 34 00 00 00 00 00 00 00 00 00 00 00 00 00 |n64.............|
00000040 00 00 00 00 00 00 00 00 73 68 61 32 35 36 00 00 |........sha256..|
00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000060 00 00 00 00 00 00 00 00 00 00 10 00 00 00 00 40 |...............@|
00000070 a7 de d2 02 b1 d5 ed 2c 52 c2 d2 bc c5 65 a2 4a |.......,R....e.J|
00000080 a9 d3 52 df af 2b 8d 00 87 88 b7 28 ef a0 9e 68 |..R..+.....(...h|
00000090 19 53 bd cc 46 a3 1d e2 d0 0f e0 32 94 0d c3 46 |.S..F......2...F|
000000a0 7e d5 ef 91 00 01 d6 96 63 64 63 61 32 39 33 65 |~.......cdca293e|
000000b0 2d 62 35 66 37 2d 34 36 38 36 2d 38 37 32 33 2d |-b5f7-4686-8723-|
000000c0 35 31 62 66 61 39 31 30 62 34 34 61 00 00 00 00 |51bfa910b44a....|
000000d0 00 ac 71 f3 00 1d bd 62 1e 0a c5 72 85 9a 95 e7 |..q....b...r....|
000000e0 ba 7b d2 98 4d b3 83 00 d1 07 93 a9 42 44 11 2c |.{..M.......BD.,|
000000f0 a3 4b f5 4c e5 b1 82 4b 00 00 00 08 00 00 0f a0 |.K.L...K........|
00000100 00 00 de ad 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000120 00 00 00 00 00 00 00 00 00 00 02 00 00 00 0f a0 |................|
00000130 00 00 de ad 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000150 00 00 00 00 00 00 00 00 00 00 03 f8 00 00 0f a0 |................|
00000160 00 00 de ad 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000180 00 00 00 00 00 00 00 00 00 00 05 f0 00 00 0f a0 |................|
00000190 00 00 de ad 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000001a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000001b0 00 00 00 00 00 00 00 00 00 00 07 e8 00 00 0f a0 |................|
000001c0 00 00 de ad 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000001d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000001e0 00 00 00 00 00 00 00 00 00 00 09 e0 00 00 0f a0 |................|
000001f0 00 00 de ad 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000210 00 00 00 00 00 00 00 00 00 00 0b d8 00 00 0f a0 |................|
00000220 00 00 de ad 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000230 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000240 00 00 00 00 00 00 00 00 00 00 0d d0 00 00 0f a0 |................|
00000250 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
-- HOME
LUKS header information for /dev/vg0/home
Version: 1
Cipher name: aes
Cipher mode: xts-plain64
Hash spec: sha256
Payload offset: 4096
MK bits: 512
MK digest: 50 c2 9a 6c 5a 98 21 77 bd 46 e0 2e 0d 01 82 f9 8d 6e db 4f
MK salt: 1e 5b cb 4c 72 5a 22 78 75 39 97 e2 cf 09 4d a5
c8 85 8a a6 2c a6 a7 bd eb 09 71 ec fb 1c ca 6e
MK iterations: 119373
UUID: e66111c9-7966-469d-911b-186c33a5ed06
Key Slot 0: ENABLED
Iterations: 1909974
Salt: 6b 73 6f 04 65 ab 09 39 09 a7 9d 5d 75 2a 52 87
81 e0 67 52 0b 9d 69 83 46 7d 0f 65 88 9f 70 a8
Key material offset: 8
AF stripes: 4000
Key Slot 1: ENABLED
Iterations: 1913458
Salt: 29 55 bb d8 70 1a 8f dc d5 12 03 37 43 a8 d5 08
02 c2 ac 9f 65 6f 13 f5 2c d1 97 fa ab 5a 75 75
Key material offset: 512
AF stripes: 4000
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED
00000000 4c 55 4b 53 ba be 00 01 61 65 73 00 00 00 00 00 |LUKS....aes.....|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000020 00 00 00 00 00 00 00 00 78 74 73 2d 70 6c 61 69 |........xts-plai|
00000030 6e 36 34 00 00 00 00 00 00 00 00 00 00 00 00 00 |n64.............|
00000040 00 00 00 00 00 00 00 00 73 68 61 32 35 36 00 00 |........sha256..|
00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000060 00 00 00 00 00 00 00 00 00 00 10 00 00 00 00 40 |...............@|
00000070 50 c2 9a 6c 5a 98 21 77 bd 46 e0 2e 0d 01 82 f9 |P..lZ.!w.F......|
00000080 8d 6e db 4f 1e 5b cb 4c 72 5a 22 78 75 39 97 e2 |.n.O.[.LrZ"xu9..|
00000090 cf 09 4d a5 c8 85 8a a6 2c a6 a7 bd eb 09 71 ec |..M.....,.....q.|
000000a0 fb 1c ca 6e 00 01 d2 4d 65 36 36 31 31 31 63 39 |...n...Me66111c9|
000000b0 2d 37 39 36 36 2d 34 36 39 64 2d 39 31 31 62 2d |-7966-469d-911b-|
000000c0 31 38 36 63 33 33 61 35 65 64 30 36 00 00 00 00 |186c33a5ed06....|
000000d0 00 ac 71 f3 00 1d 24 d6 6b 73 6f 04 65 ab 09 39 |..q...$.kso.e..9|
000000e0 09 a7 9d 5d 75 2a 52 87 81 e0 67 52 0b 9d 69 83 |...]u*R...gR..i.|
000000f0 46 7d 0f 65 88 9f 70 a8 00 00 00 08 00 00 0f a0 |F}.e..p.........|
00000100 00 ac 71 f3 00 1d 32 72 29 55 bb d8 70 1a 8f dc |..q...2r)U..p...|
00000110 d5 12 03 37 43 a8 d5 08 02 c2 ac 9f 65 6f 13 f5 |...7C.......eo..|
00000120 2c d1 97 fa ab 5a 75 75 00 00 02 00 00 00 0f a0 |,....Zuu........|
00000130 00 00 de ad 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000150 00 00 00 00 00 00 00 00 00 00 03 f8 00 00 0f a0 |................|
00000160 00 00 de ad 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000180 00 00 00 00 00 00 00 00 00 00 05 f0 00 00 0f a0 |................|
00000190 00 00 de ad 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000001a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000001b0 00 00 00 00 00 00 00 00 00 00 07 e8 00 00 0f a0 |................|
000001c0 00 00 de ad 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000001d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000001e0 00 00 00 00 00 00 00 00 00 00 09 e0 00 00 0f a0 |................|
000001f0 00 00 de ad 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000210 00 00 00 00 00 00 00 00 00 00 0b d8 00 00 0f a0 |................|
00000220 00 00 de ad 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000230 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000240 00 00 00 00 00 00 00 00 00 00 0d d0 00 00 0f a0 |................|
00000250 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
-- found in /proc/crypto
name : __xts(aes)
driver : cryptd(__xts-aes-aesni)
module : cryptd
priority : 451
refcnt : 1
selftest : passed
internal : yes
type : skcipher
async : yes
blocksize : 16
min keysize : 32
max keysize : 64
ivsize : 16
chunksize : 16
walksize : 16
name : xts(aes)
driver : xts-aes-aesni
module : aesni_intel
priority : 401
refcnt : 1
selftest : passed
internal : no
type : skcipher
async : yes
blocksize : 16
min keysize : 32
max keysize : 64
ivsize : 16
chunksize : 16
walksize : 16
name : __xts(aes)
driver : __xts-aes-aesni
module : aesni_intel
priority : 401
refcnt : 1
selftest : passed
internal : yes
type : skcipher
async : no
blocksize : 16
min keysize : 32
max keysize : 64
ivsize : 16
chunksize : 16
walksize : 16
name : __aes
driver : __aes-aesni
module : aesni_intel
priority : 300
refcnt : 1
selftest : passed
internal : yes
type : cipher
blocksize : 16
min keysize : 16
max keysize : 32
name : aes
driver : aes-aesni
module : aesni_intel
priority : 300
refcnt : 5
selftest : passed
internal : no
type : cipher
blocksize : 16
min keysize : 16
max keysize : 32
name : aes
driver : aes-asm
module : aes_x86_64
priority : 200
refcnt : 1
selftest : passed
internal : no
type : cipher
blocksize : 16
min keysize : 16
max keysize : 32
name : aes
driver : aes-generic
module : kernel
priority : 100
refcnt : 2
selftest : passed
internal : no
type : cipher
blocksize : 16
min keysize : 16
max keysize : 32
Loaded modules: aesni_intel, aes_x86_64, xts, dm_mod, crypto_simd, cryptd, and dm_crypt.
[-- Attachment #2: Type: text/html, Size: 77381 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [dm-crypt] Anyone know why I can't access my volumes?
2019-10-20 21:53 [dm-crypt] Anyone know why I can't access my volumes? Philipp Rösch
@ 2019-10-21 7:50 ` Michael Kjörling
2019-10-21 14:33 ` Philipp Rösch
0 siblings, 1 reply; 15+ messages in thread
From: Michael Kjörling @ 2019-10-21 7:50 UTC (permalink / raw)
To: dm-crypt
On 20 Oct 2019 21:53 +0000, from philipp@pm.me (Philipp Rösch):
> I installed Arch Linux about a year ago with LUKS on LVM. After an
> update and reboot I can no longer access the volumes: "No key
> available with this passphrase."
That, to me, immediately makes the update suspect. Do you remember
what was updated? The kernel? Keyboard utilities or data? Any
LUKS-related packages? Was a new initramfs generated? Anything else
that might possibly be relevant for the early boot process?
Are you able to download bootable live/rescue media and boot from
that, then try to open the LUKS container from within that
environment? That should allow you to experiment more, since you will
have a fuller environment than the early boot environment. If it works
from within a live environment, then at least you know that it's
something about your installed system, not the data on disk as such.
I strongly recommend that you make at least a header backup, if you
haven't already, just in case something goes further wrong.
--
Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
“The most dangerous thought that you can have as a creative person
is to think you know what you’re doing.” (Bret Victor)
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [dm-crypt] Anyone know why I can't access my volumes?
2019-10-21 7:50 ` Michael Kjörling
@ 2019-10-21 14:33 ` Philipp Rösch
2019-10-21 14:50 ` Arno Wagner
0 siblings, 1 reply; 15+ messages in thread
From: Philipp Rösch @ 2019-10-21 14:33 UTC (permalink / raw)
To: Michael Kjörling; +Cc: dm-crypt
On Monday, October 21, 2019 7:50 AM, Michael Kjörling <michael@kjorling.se> wrote:
> That, to me, immediately makes the update suspect. Do you remember
> what was updated? The kernel? Keyboard utilities or data? Any
> LUKS-related packages? Was a new initramfs generated? Anything else
> that might possibly be relevant for the early boot process?
Unfortunately I ran the updates while doing other things. Done that dozens of times without checking... I asume that a new kernel and initramfs were installed just because it's been a while since my last update.
> Are you able to download bootable live/rescue media and boot from
> that, then try to open the LUKS container from within that
> environment? That should allow you to experiment more, since you will
> have a fuller environment than the early boot environment. If it works
> from within a live environment, then at least you know that it's
> something about your installed system, not the data on disk as such.
I tried booting from a year old Arch Linux USB, and the most recent one, and I can't unlock the volumes with the correct passphrase (please see my original mail). I looked everywhere and don't understand *why* it doesn't work.
> I strongly recommend that you make at least a header backup, if you
> haven't already, just in case something goes further wrong.
I did now, unfortunately I didn't do this before.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [dm-crypt] Anyone know why I can't access my volumes?
2019-10-21 14:33 ` Philipp Rösch
@ 2019-10-21 14:50 ` Arno Wagner
2019-10-21 14:56 ` Philipp Rösch
0 siblings, 1 reply; 15+ messages in thread
From: Arno Wagner @ 2019-10-21 14:50 UTC (permalink / raw)
To: Philipp Rösch; +Cc: Michael Kjörling, dm-crypt
Maybe a keyboard layout issue, like z and y being switched?
Regards,
Arno
On Mon, Oct 21, 2019 at 16:33:50 CEST, Philipp Rösch wrote:
[...[
> I tried booting from a year old Arch Linux USB, and the most recent one, and I can't unlock the volumes with the correct passphrase (please see my original mail). I looked everywhere and don't understand *why* it doesn't work.
>
> > I strongly recommend that you make at least a header backup, if you
> > haven't already, just in case something goes further wrong.
>
> I did now, unfortunately I didn't do this before.
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> https://www.saout.de/mailman/listinfo/dm-crypt
--
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@wagner.name
GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato
If it's in the news, don't worry about it. The very definition of
"news" is "something that hardly ever happens." -- Bruce Schneier
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [dm-crypt] Anyone know why I can't access my volumes?
2019-10-21 14:50 ` Arno Wagner
@ 2019-10-21 14:56 ` Philipp Rösch
2019-10-24 7:26 ` Carl-Daniel Hailfinger
0 siblings, 1 reply; 15+ messages in thread
From: Philipp Rösch @ 2019-10-21 14:56 UTC (permalink / raw)
To: Arno Wagner; +Cc: Michael Kjörling, dm-crypt
> Maybe a keyboard layout issue, like z and y being switched?
Quadruple checked this and tried a keyfile, even checked its hexdump -C and tried with and without a newline.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [dm-crypt] Anyone know why I can't access my volumes?
2019-10-21 14:56 ` Philipp Rösch
@ 2019-10-24 7:26 ` Carl-Daniel Hailfinger
2019-10-24 12:34 ` Arno Wagner
2019-10-24 19:35 ` Philipp Rösch
0 siblings, 2 replies; 15+ messages in thread
From: Carl-Daniel Hailfinger @ 2019-10-24 7:26 UTC (permalink / raw)
To: Philipp Rösch; +Cc: dm-crypt
On 21.10.19 16:56, Philipp Rösch wrote:
>> Maybe a keyboard layout issue, like z and y being switched?
> Quadruple checked this and tried a keyfile, even checked its hexdump -C and tried with and without a newline.
Have you tried intentionally switching z and y or whatever your keyboard
layout differences are to US keyboard, i.e. using a mangled password
instead of the correct one? I once used a distro (don't remember which)
where entering the key during bootup used a different keyboard layout
from what the booted system had by default. Unlocking it with the
correct passphrase from a booted system obviously didn't work, and it
took me some digging to figure out the reason.
Then again, if unlocking with a key file (if that used to work) fails,
the issues are obviously bigger. If you have the passphrase written down
somewhere, checking again that you're remembering it correctly is a
suggestion of last resort.
What looks a bit inconsistent in your case is one used keyslot for the
root volume and two used keyslots for the home volume.
Can you try booting with the old installed kernel and initrd? Usually
those are kept for some time after an upgrade.
Another thing I had to debug recently for a colleague was a failing
flash medium. There were no read errors, but single bits of the data had
flipped. A unreported bit flip affecting the keyslots would be
catastrophic AFAICS. That said, bitflips affecting only the keyslots and
nothing else would be a strange beast unless this is a really crappy
SSD. How often do you reboot during normal operation?
Regards,
Carl-Daniel
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [dm-crypt] Anyone know why I can't access my volumes?
2019-10-24 7:26 ` Carl-Daniel Hailfinger
@ 2019-10-24 12:34 ` Arno Wagner
2019-10-24 19:35 ` Philipp Rösch
1 sibling, 0 replies; 15+ messages in thread
From: Arno Wagner @ 2019-10-24 12:34 UTC (permalink / raw)
To: dm-crypt
On Thu, Oct 24, 2019 at 09:26:11 CEST, Carl-Daniel Hailfinger wrote:
[...]
> Can you try booting with the old installed kernel and initrd? Usually
> those are kept for some time after an upgrade.
You may also be able to get them from an archive. Most distros keep
older versions arpound for a while.
> Another thing I had to debug recently for a colleague was a failing
> flash medium. There were no read errors, but single bits of the data had
> flipped.
I had that as well on an USB-stick. An exceptionally bad design
that obviously did without the checksums that all well-designed
storage has.
> A unreported bit flip affecting the keyslots would be
> catastrophic AFAICS.
A single bit will kill the keyslot. If you know it is a single bit
only, you can try with all bits flipped (around 1M tries taking
around 2 weeks with 1 sec per try, i.e. all other keyslosts disabled),
but if it is two bits, you are already pretty much screwed.
> That said, bitflips affecting only the keyslots and
> nothing else would be a strange beast unless this is a really crappy
> SSD. How often do you reboot during normal operation?
It could be a very small number of bits affected. Also, bit-flips
in documents and even software often go unnoticed for a while.
That is why you should allways do a full compare in backups.
I found weak RAM bits, defective HDD connectors, etc. that way
in the past.
Regards,
Arno
--
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@wagner.name
GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato
If it's in the news, don't worry about it. The very definition of
"news" is "something that hardly ever happens." -- Bruce Schneier
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [dm-crypt] Anyone know why I can't access my volumes?
2019-10-24 7:26 ` Carl-Daniel Hailfinger
2019-10-24 12:34 ` Arno Wagner
@ 2019-10-24 19:35 ` Philipp Rösch
2019-12-10 16:34 ` Philipp Rösch
1 sibling, 1 reply; 15+ messages in thread
From: Philipp Rösch @ 2019-10-24 19:35 UTC (permalink / raw)
To: Carl-Daniel Hailfinger; +Cc: dm-crypt
> Have you tried intentionally switching z and y or whatever your keyboard
> layout differences are to US keyboard, i.e. using a mangled password
> instead of the correct one?
I tried tried all possible combinations between US and my German layout with a script.
> Then again, if unlocking with a key file (if that used to work) fails,
> the issues are obviously bigger. If you have the passphrase written down
> somewhere, checking again that you're remembering it correctly is a
> suggestion of last resort.
I have it written down, the passphrase is 100% correct. (The script was superfluous
but I didn't know what else to do.)
> What looks a bit inconsistent in your case is one used keyslot for the
> root volume and two used keyslots for the home volume.
Yes. Inside root is a keyfile to automatically unlock home but home also has a key
with the same passphrase as root. Not entirely sure why I set it up that way.
> Can you try booting with the old installed kernel and initrd? Usually those are
kept for some time after an upgrade.
None of the fallback options work:
mount: /new_root: no filesystem type specified.
You are now being dropped into an emergency shell.
sh: can't access tty; job control turned off.
> Another thing I had to debug recently for a colleague was a failing
> flash medium. There were no read errors, but single bits of the data had
> flipped. A unreported bit flip affecting the keyslots would be
> catastrophic AFAICS. That said, bitflips affecting only the keyslots and
> nothing else would be a strange beast unless this is a really crappy
> SSD. How often do you reboot during normal operation?
I probably update and reboot every 2-6 weeks. This is a year old Dell XPS 9370
with a Toshiba SSD. Its SMART outpus looks OK to me.
I posted luksDump and hexdump of the first sectors in my original mail. Wouldn't
you see such corruption there, or with chk_luks_keyslots?
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [dm-crypt] Anyone know why I can't access my volumes?
2019-10-24 19:35 ` Philipp Rösch
@ 2019-12-10 16:34 ` Philipp Rösch
2019-12-10 17:42 ` Chris Murphy
2019-12-10 21:51 ` Arno Wagner
0 siblings, 2 replies; 15+ messages in thread
From: Philipp Rösch @ 2019-12-10 16:34 UTC (permalink / raw)
To: Carl-Daniel Hailfinger; +Cc: dm-crypt
Sorry for the late late reply.
It was indeed the wrong keyboard layout. Imagine that...
I was about to give up when I noticed different German layout variations on my live disk. One of those worked. Surprise.
My case seemed strange because everything looked ok and there were no errors anywhere, except that the volumes wouldn't unlock.
PEBKC.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, October 24, 2019 8:35 PM, Philipp Rösch <philipp@pm.me> wrote:
> > Have you tried intentionally switching z and y or whatever your keyboard
>
> > layout differences are to US keyboard, i.e. using a mangled password
> > instead of the correct one?
>
> I tried tried all possible combinations between US and my German layout with a script.
>
> > Then again, if unlocking with a key file (if that used to work) fails,
> > the issues are obviously bigger. If you have the passphrase written down
> > somewhere, checking again that you're remembering it correctly is a
> > suggestion of last resort.
>
> I have it written down, the passphrase is 100% correct. (The script was superfluous
> but I didn't know what else to do.)
>
> > What looks a bit inconsistent in your case is one used keyslot for the
> > root volume and two used keyslots for the home volume.
>
> Yes. Inside root is a keyfile to automatically unlock home but home also has a key
> with the same passphrase as root. Not entirely sure why I set it up that way.
>
> > Can you try booting with the old installed kernel and initrd? Usually those are
>
> kept for some time after an upgrade.
>
> None of the fallback options work:
>
> mount: /new_root: no filesystem type specified.
> You are now being dropped into an emergency shell.
> sh: can't access tty; job control turned off.
>
> > Another thing I had to debug recently for a colleague was a failing
> > flash medium. There were no read errors, but single bits of the data had
> > flipped. A unreported bit flip affecting the keyslots would be
> > catastrophic AFAICS. That said, bitflips affecting only the keyslots and
> > nothing else would be a strange beast unless this is a really crappy
> > SSD. How often do you reboot during normal operation?
>
> I probably update and reboot every 2-6 weeks. This is a year old Dell XPS 9370
> with a Toshiba SSD. Its SMART outpus looks OK to me.
>
> I posted luksDump and hexdump of the first sectors in my original mail. Wouldn't
> you see such corruption there, or with chk_luks_keyslots?
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [dm-crypt] Anyone know why I can't access my volumes?
2019-12-10 16:34 ` Philipp Rösch
@ 2019-12-10 17:42 ` Chris Murphy
2019-12-10 20:00 ` Michael Kjörling
2019-12-10 21:51 ` Arno Wagner
1 sibling, 1 reply; 15+ messages in thread
From: Chris Murphy @ 2019-12-10 17:42 UTC (permalink / raw)
To: Philipp Rösch; +Cc: Carl-Daniel Hailfinger, dm-crypt
On Tue, Dec 10, 2019 at 9:44 AM Philipp Rösch <philipp@pm.me> wrote:
>
> Sorry for the late late reply.
>
> It was indeed the wrong keyboard layout. Imagine that...
>
> I was about to give up when I noticed different German layout variations on my live disk. One of those worked. Surprise.
Interesting. If you have time to write up a brief summary with one or
two screenshots demonstrating the confusion: in particular I'd like to
see how the UI presents these two different layouts, how non-obvious
it is, which one works and which one doesn't work. That would be
great.
I'm looking for clear examples of how users are betrayed by the user
interface. Obviously if you had not persisted, and had resigned to
data loss instead, it shifts the penalty of inadequate design onto the
user. And that's inappropriate.
> My case seemed strange because everything looked ok and there were no errors anywhere, except that the volumes wouldn't unlock.
Yea, the likely cause for this is there may be no way of
distinguishing between wrong passphrase and wrong encoding. I doubt
the LUKS2 header contains any kind of hint as to what encodings were
used when setting the passphrase. I'm curious if security experts
could assess to what degree that information makes it easier to brute
force attack a passphrase?
Super simplistically, you have multiple layers of encoding between
you+yourpassphrase, and the actual representation of that passphrase
stored on disk. If any of those encodings change, it's functionally no
different than entering the wrong passphrase. Same with all the other
transforms done on your passphrase to make it stronger: salt,
iterations, key derivation function. If those aren't correct every
time, functionally it's the same as wrong passphrase entry. It's a
binary outcome.
A possible better workaround for this problem, is helping the user
create a recovery passphrase, and maybe even some desktop environments
or installers go with a policy where the user is taken through this by
default. That'd be a randomly generated passphrase, limited character
set (perhaps ASCII), so that it's unambiguous. There is a bias,
predicating it on Latin input. But it's better than data loss! And
then display that recovery passphrase for the user to escrow somewhere
safe. And then almost any keymapping or keyboard still gets the
encoding for this passphrase correct.
If an attacker sees more than one keyslot used, and assumes one is a
recovery key, and assumes the passphrase is ASCII, haven't they
improved their bruteforce attack capability? And that comes full
circle back to whether the keymapping and keyboard locale information
should be stored somewhere, and checked at passphrase entry time, and
the user warned if there's a mismatch.
--
Chris Murphy
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [dm-crypt] Anyone know why I can't access my volumes?
2019-12-10 17:42 ` Chris Murphy
@ 2019-12-10 20:00 ` Michael Kjörling
2019-12-10 21:18 ` Chris Murphy
0 siblings, 1 reply; 15+ messages in thread
From: Michael Kjörling @ 2019-12-10 20:00 UTC (permalink / raw)
To: dm-crypt
On 10 Dec 2019 10:42 -0700, from lists@colorremedies.com (Chris Murphy):
> A possible better workaround for this problem, is helping the user
> create a recovery passphrase, and maybe even some desktop environments
> or installers go with a policy where the user is taken through this by
> default. That'd be a randomly generated passphrase, limited character
> set (perhaps ASCII), so that it's unambiguous. There is a bias,
> predicating it on Latin input. But it's better than data loss! And
> then display that recovery passphrase for the user to escrow somewhere
> safe. And then almost any keymapping or keyboard still gets the
> encoding for this passphrase correct.
>
> If an attacker sees more than one keyslot used, and assumes one is a
> recovery key, and assumes the passphrase is ASCII, haven't they
> improved their bruteforce attack capability? And that comes full
> circle back to whether the keymapping and keyboard locale information
> should be stored somewhere, and checked at passphrase entry time, and
> the user warned if there's a mismatch.
As you say, it's not _just_ an encoding problem.
There's character encoding, particularly but not exclusively for
non-US-English characters (0-9, A-Z, some punctuation). (This is the
mapping from glyphs on the screen to bits and bytes in memory.)
There's keyboard layout. (This is the mapping from physical key to
glyphs on the screen.)
Particularly on laptops, there's also the issue that some have an
integrated numeric keypad _overlaid on the alphanumeric portion of the
keyboard_, which can definitely trip you up.
If you're unlucky, there's a flaky key switch which causes a key
stroke to not register properly.
And probably one or two things I'm forgetting at the moment.
For a recovery passphrase in particular, I'd suggest going with the
restricted character set that Yubikeys use (termed "modhex"), as that
is specifically selected to work across as wide a range of keyboard
layouts as possible. Wikipedia gives that character set as
[cbdefghijklnrtuv] (16 characters, mapping to hexadecimal digits).
Brute force attacks on the passphrases are only feasible if the
passphrase is short and/or otherwise poorly selected. A recovery
passphrase can be long, random, and use a very high iteration count if
so desired; you get a 2^256 work factor (given what we know today,
more than enough for anyone who doesn't plan to outlast the heat death
of the universe) with just 64 modhex characters, even if the attacker
knows how the passphrase was generated, as long as it's properly
_random_. That's _plenty_ short enough to write down by hand on a
piece of paper. If you're paranoid, add to that a few seconds' worth
of iteration count, and attacking that passphrase is in no way easier,
and quite likely harder, than attacking the master key directly.
--
Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [dm-crypt] Anyone know why I can't access my volumes?
2019-12-10 20:00 ` Michael Kjörling
@ 2019-12-10 21:18 ` Chris Murphy
0 siblings, 0 replies; 15+ messages in thread
From: Chris Murphy @ 2019-12-10 21:18 UTC (permalink / raw)
To: Michael Kjörling; +Cc: dm-crypt
On Tue, Dec 10, 2019 at 1:03 PM Michael Kjörling <michael@kjorling.se> wrote:
>
> On 10 Dec 2019 10:42 -0700, from lists@colorremedies.com (Chris Murphy):
> > A possible better workaround for this problem, is helping the user
> > create a recovery passphrase, and maybe even some desktop environments
> > or installers go with a policy where the user is taken through this by
> > default. That'd be a randomly generated passphrase, limited character
> > set (perhaps ASCII), so that it's unambiguous. There is a bias,
> > predicating it on Latin input. But it's better than data loss! And
> > then display that recovery passphrase for the user to escrow somewhere
> > safe. And then almost any keymapping or keyboard still gets the
> > encoding for this passphrase correct.
> >
> > If an attacker sees more than one keyslot used, and assumes one is a
> > recovery key, and assumes the passphrase is ASCII, haven't they
> > improved their bruteforce attack capability? And that comes full
> > circle back to whether the keymapping and keyboard locale information
> > should be stored somewhere, and checked at passphrase entry time, and
> > the user warned if there's a mismatch.
>
> As you say, it's not _just_ an encoding problem.
>
> There's character encoding, particularly but not exclusively for
> non-US-English characters (0-9, A-Z, some punctuation). (This is the
> mapping from glyphs on the screen to bits and bytes in memory.)
>
> There's keyboard layout. (This is the mapping from physical key to
> glyphs on the screen.)
>
> Particularly on laptops, there's also the issue that some have an
> integrated numeric keypad _overlaid on the alphanumeric portion of the
> keyboard_, which can definitely trip you up.
>
> If you're unlucky, there's a flaky key switch which causes a key
> stroke to not register properly.
>
> And probably one or two things I'm forgetting at the moment.
>
> For a recovery passphrase in particular, I'd suggest going with the
> restricted character set that Yubikeys use (termed "modhex"), as that
> is specifically selected to work across as wide a range of keyboard
> layouts as possible. Wikipedia gives that character set as
> [cbdefghijklnrtuv] (16 characters, mapping to hexadecimal digits).
Good suggestion.
>
> Brute force attacks on the passphrases are only feasible if the
> passphrase is short and/or otherwise poorly selected. A recovery
> passphrase can be long, random, and use a very high iteration count if
> so desired; you get a 2^256 work factor (given what we know today,
> more than enough for anyone who doesn't plan to outlast the heat death
> of the universe) with just 64 modhex characters, even if the attacker
> knows how the passphrase was generated, as long as it's properly
> _random_. That's _plenty_ short enough to write down by hand on a
> piece of paper. If you're paranoid, add to that a few seconds' worth
> of iteration count, and attacking that passphrase is in no way easier,
> and quite likely harder, than attacking the master key directly.
Understood. As long as the recovery passphrase is not significantly
more crackable than a reasonably sophisticated user's passphrase,
they're not *worse* off with a recovery passphrase being set for them.
And a sophisticated user could choose to use luksKillSlot to remove
it.
--
Chris Murphy
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [dm-crypt] Anyone know why I can't access my volumes?
2019-12-10 16:34 ` Philipp Rösch
2019-12-10 17:42 ` Chris Murphy
@ 2019-12-10 21:51 ` Arno Wagner
1 sibling, 0 replies; 15+ messages in thread
From: Arno Wagner @ 2019-12-10 21:51 UTC (permalink / raw)
To: dm-crypt
Thanks for the feedback. It is really important to know how
these things happen. It is a good idea to stay within the standard
ASCII char-set for passwords and passphrases. (The "special char"
requirement some people have is really, really stupid.) Then, on a
German keyboard you only have the y/z swap, and that you usually
can just test out.
If in doubt, just make it one or two chars or words longer.
Personally, I have even dropped uppercase letters.
The problem with anything outside of standard ASCII is that the
encoding is really messed up and variable. Unicode was supposed
to solve that, but for this application it made things even
worse.
Regards,
Arno
On Tue, Dec 10, 2019 at 17:34:22 CET, Philipp Rösch wrote:
> Sorry for the late late reply.
>
> It was indeed the wrong keyboard layout. Imagine that...
>
> I was about to give up when I noticed different German layout variations
> on my live disk. One of those worked. Surprise.
>
> My case seemed strange because everything looked ok and there were no
> errors anywhere, except that the volumes wouldn't unlock.
>
> PEBKC.
>
>
--
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@wagner.name
GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato
If it's in the news, don't worry about it. The very definition of
"news" is "something that hardly ever happens." -- Bruce Schneier
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [dm-crypt] Anyone know why I can't access my volumes?
@ 2019-10-21 18:16 Arno Wagner
2019-10-21 18:23 ` Philipp Rösch
0 siblings, 1 reply; 15+ messages in thread
From: Arno Wagner @ 2019-10-21 18:16 UTC (permalink / raw)
To: dm-crypt
On Mon, Oct 21, 2019 at 16:56:27 CEST, Philipp Rösch wrote:
> > Maybe a keyboard layout issue, like z and y being switched?
>
> Quadruple checked this and tried a keyfile, even checked its hexdump -C
> and tried with and without a newline.
Strange.
Have you tried the keyslot-checker?
It is in /misc/ of the original source-tree and
it can spot areas in keyslots that have been
overwritten with low-entropy data.
Regards,
Arno
--
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@wagner.name
GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato
If it's in the news, don't worry about it. The very definition of
"news" is "something that hardly ever happens." -- Bruce Schneier
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2019-12-10 21:51 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-10-20 21:53 [dm-crypt] Anyone know why I can't access my volumes? Philipp Rösch
2019-10-21 7:50 ` Michael Kjörling
2019-10-21 14:33 ` Philipp Rösch
2019-10-21 14:50 ` Arno Wagner
2019-10-21 14:56 ` Philipp Rösch
2019-10-24 7:26 ` Carl-Daniel Hailfinger
2019-10-24 12:34 ` Arno Wagner
2019-10-24 19:35 ` Philipp Rösch
2019-12-10 16:34 ` Philipp Rösch
2019-12-10 17:42 ` Chris Murphy
2019-12-10 20:00 ` Michael Kjörling
2019-12-10 21:18 ` Chris Murphy
2019-12-10 21:51 ` Arno Wagner
2019-10-21 18:16 Arno Wagner
2019-10-21 18:23 ` Philipp Rösch
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.