Unable to mount LUKS-encrypted disk

[a5s397]

Dear Armbian supporters,

 

Using kernel 5.10.21-rockchip64 on Rock Pi 4 (and 5.10.21-sunxi on Lime2), I am not able to mount a LUKS-encrypted drive. Changing the kernel to 5.10.16-rockchip64/5.10.16-sunxi I am able to mount the LUKS-encrypted drive again. Error message when trying to mount the drive is: "No key available with this passphrase". Which change could have introduced this bug?

 

Greetings

a5s397

[lanefu]

compare the results of

 

zcat /proc/config.gz between the two kernels please

[a5s397]

Unfortunately the issue also exists with 5.10.43-rockchip. Here is the diff of it:

 

3c3
< # Linux/arm64 5.10.16 Kernel Configuration
---
> # Linux/arm64 5.10.43 Kernel Configuration
228a229
> CONFIG_KCMP=y
433a435
> CONFIG_AS_HAS_LSE_ATOMICS=y
839c841
< CONFIG_BINFMT_MISC=y
---
> CONFIG_BINFMT_MISC=m
1910d1911
< # CONFIG_PCIE_BW is not set
3236a3238
> CONFIG_RTL8188EU=m
7356a7359
> CONFIG_EXTCON_USBC_VIRTUAL_PD=y
7445d7447
< # CONFIG_AD9467 is not set
7928d7929
< # CONFIG_USB_LGM_PHY is not set
8398c8399
< CONFIG_NLS_ASCII=m
---
> CONFIG_NLS_ASCII=y

 

Is there anything pointing towards an issue with mounting encrypted drives with LUKS?

[tparys]

On 6/28/2021 at 4:10 PM, a5s397 said:

Unfortunately the issue also exists with 5.10.43-rockchip. Here is the diff of it:

 

I think @lanefu was referring to doing a diff between the configs of the rockchip64 kernel which does not work, and the sunxi kernel which does.

 

Based on the error, I'd wager the keyslot open is failing because you're missing a hash function. Believe the default is SHA1, unless you specified something different. Running "cryptsetup luksDump /dev/sda1" or whatever, should tell you for sure.

 

If your system has AF_ALG compiled in, you can also run "cryptsetup benchmark", which runs typical hash and cipher algorithms used by LUKS. If it fails on something, that could be a clue.

[a5s397]

Thanks for your answer @tparys. Maybe my first post was misunderstanding, but the problem exists for both boards (rockchip64 and sunxi), while the older version of the kernel (5.10.16-rockchip64 and 5.10.16-sunxi) works with luksOpening the LUKS-drive and newer kernels on both platforms up to 5.10.43 do not work ("No key available with this passphrase"). I will check back concerning the missing of a hash function, but I did not encounter any problems since working with the newer kernels concerning hash functions.

 

[tparys]

Interesting.

 

Just remembered that my NanoPi M4V2 also uses the same RK3399 as your Rock Pi 4, and using the rockchip64 kernel. Offhand it seems to be working as expected with a test volume using default parameters. Kernel 5.10.43-rockchip64.

 

I hate to suggest it, but is your MicroSD / SSD failing? If so you'd see lots of lost errors about lost DMA pages in the output of dmesg.

 

You can also try to mount that volume on a separate PC, to verify the problem is with the board and not the card/disk.

 

console.txt

[djurny]

Hi @a5s397,

I also had some issues with my LUKS encrypted partitions after a kernel upgrade before, but I have a hard time remembering what actually happened and how I managed to get it working again.

 

Perhaps I'm stating the obvious, but are you sure you have a LUKS or LUKS2 type setup on your drive? As for me, I had to recompile LUKS2 in the past to get it to work for sure. Cannot really recall about the ... stopping here, just read your console.txt and you indeed have a LUKS2 format.

 

Can you paste the output of cryptsetup --version and a syslog or dmesg output just before, during and after your first initial attempt to luksOpen your device on the working and non-working setups?

 

Groetjes,

[tparys]

@djurny, the console log was from my system, which appears to be working fine. And strictly speaking, LUKS is only an on-disk format, so there's really nothing that you can recompile. You can recompile the kernel (for missing features / ciphers), or cryptsetup (which is generally provided from upstream). But I'd be curious to hear exactly what your problems were and what you had to do.

 

@a5s397, "cryptsetup luksDump /path/to/volume" should identify whether LUKS 1 or 2 is in use, as well as any other chosen parameters. If you still need help, you'll need to provide some more information. Otherwise, there's not enough here to go on.

[djurny]

Hi @tparys,

LUKS2 on-disk format is not supported/understood by cryptsetup 1.x, it requires cryptsetup 2.0 or higher. At that time, I do recall I had to build it (cryptsetup 2.x) from source on my Helios4 and Helios64 boxes which were at 4.4.x back then.

 

As mentioned, my memory is failing here as I cannot recollect or find any logs on the actual errors I encountered, but the errors thrown at me by LUKS(1) were putting me on all my wrong feet at that time.

 

Anyhow, I thought it is worth to check out to see if this might help out - or not of course.

 

Groetjes,

[tparys]

On 7/6/2021 at 12:01 AM, djurny said:

Hi @tparys,

LUKS2 on-disk format is not supported/understood by cryptsetup 1.x, it requires cryptsetup 2.0 or higher. At that time, I do recall I had to build it (cryptsetup 2.x) from source on my Helios4 and Helios64 boxes which were at 4.4.x back then.

 

That makes more sense. But if you had built a LUKS v1 volume on that system, it should have worked, just without some of the newer features that LUKS v2 gives you. Though that probably would have been needed if you wanted to use the 4k block size, Argon password hash, or an external drive you set up on a different system.

 

Unfortunately, probably nothing that helps with the posted question.

[a5s397]

Thank you for your answers so far. My version of cryptsetup is 2.1.0, however I managed to mount the LUKS-drive with the newer kernels with setting another (shorter) passphrase on the older kernel, which was working with the encrypted drive. I will mark this issue as solved.

 

Is there a bug in setting a (too) long passphrase for LUKS-encrypted drives without getting a warning? There should (in theory) not be a limit according to https://askubuntu.com/questions/487613/luks-hdd-encryption-maximum-maximum-password-length

[tparys]

10 hours ago, a5s397 said:

Is there a bug in setting a (too) long passphrase for LUKS-encrypted drives without getting a warning?

 

Not that I'm aware of. Longer passwords are generally encouraged. Though you will eventually hit a point where longer passwords aren't buying you any more security.

 

Of course, that depends on the cipher / key size you're using, how long your password is and what sort of characters it's made of (read: entropy).