Dear Maintainers, Guilhem, Jonas, (and Tim),

First of all: thanks a lot for maintaining cryptsetup-suspend!

I changed my LUKS-Encryption to using a gpg-keyfile, together with a nitrokey
Pro (and gnupg-sc). Booting works without any problems, but when resuming from
suspend, instead of the pinentry-field (I'm using pinentry-curses) there's just
the message "No key available with this passphrase". This is repeatedly printed
(about every second), and the CPU immediately runs hot - so, just forcing a
shutdown helps.

The keyfile/initramfs/cryptsetup is done exactly in the way the gnupg-sc-doc
outlines this; the GPG-keyfile is pinned to Slot 1, whereas Slot 0 houses my
(conventional) former passphrase. I'm running a debian system with kernel 5.14
and KDE; cryptsetup from debian testing (2.4.2-1).

To verify this behaviour, I set up a debian stable (bullseye) with gnome and no
further modifications, except cryptsetup pinned from debian testing. I used my
nitrokey Pro first, and afterwards configured a Yubikey with the same GPG key:
Exactly the same behaviour on this out-of-the-box system.

There also is no fallback to my (conventional) former passphrase (Slot 0)
(which is good: this shouldn't be happening if not set). If LUKS-setup is done
with GPG keyfile, smartcard and gnupg-sc, resuming (and decrypting) should run
from the external (smart-card-) private key.

Would be awesome if somebody of you could find the time to fix this bug!

All the best