yubikey-full-disk-encryption VS booster

Would using this be possible? https://github.com/agherzan/yubikey-full-disk-encryption/tree/master/src

> Hibernate is less interesting, and apparently unsupported using secure boot anyway.

That's not the case. I have a similar setup to yours (/ on ext4 with separate swap, on LVM on LUKS, separate /efi) and my box hibernates just fine with secure boot and auto-unlock via TPM.

The difference with your setup is I don't use grub, but have the UEFI load a signed unified kernel image directly. Since this works so well, I never had a reason to mess around with yet another moving piece (grub or other bootloader).

As another commenter said, I haven't attempted to mess around with the MOK. I just replaced all the secure boot keys with my own, and I've also signed MS's Windows key (but not the 3rd party one) for my dual-boot needs.

---

For specifics: This is an up-to-date Arch Linux install, running on an HP EliteBook 840 G8 (11th gen intel). I know Debian may have older components than arch, but this setup has been working for more than a year now.

IIRC, the most significant change was brought by systemd 251 which started supporting auto-unlocking LUKS with the TPM. Before that, on an older computer with the same general setup, hibernation worked well, too. I just needed to input the unlock password (which I was too lazy to do, so I just used my yubikey - see https://github.com/agherzan/yubikey-full-disk-encryption).

Does yubikey-full-disk-encryption provide anything systemd 253 doesn't now?

Do you mean something like this: https://github.com/agherzan/yubikey-full-disk-encryption

Full disk encryption is rarely as portable as simply encrypting the files you need. When I ran a “homemade” NAS, I had everything LUKS encrypted. I used a Yubikey to unlock the encrypted data.

A few days ago I akquiriere a Yubikey and I'm currently trying to set up 2FA with the Yubikey and a password to unlock the LUKS container. Since I am running Arch I came across the yubikey-full-disk-encryption package and tested it in an Arch VM. So far it worked really well. The only issue I am having is that compared to my old setup I need to have /boot unencrypted because it seems GRUB itself cannot deal with the 2FA setup and ykfde if /boot is encrypted. Previously I had most of /boot inside the LUKS volume with only the /efi part unencrypted (this is used when telling grub where the efi-directory is - see the previous guide for the full details please) and the GRUB_ENABLE_CRYPTODISK=y option set in the GRUB config.

I don't know about the hanging, I use yubikey-full-disk-encryption which uses challenge-response (1FA or 2FA) which you can set up how many attempts to use the YubiKey before it falls back to the passphrase.

Related: https://github.com/agherzan/yubikey-full-disk-encryption

https://github.com/cornelinux/yubikey-luks or https://github.com/agherzan/yubikey-full-disk-encryption with yubikey 5 will get you going. It is a bit expensive to get two keys (regular and backup), but these can be also used to secure most of the online accounts.

People should stop using plain passwords to protect data and switch to something better.oster/ + Yubikey

Change from mkinitcpio to booster. It's faster and produce smaller images.

Neither, use booster.

Booster is an initramfs - a type of software that runs early during the boot process and helps to setup system, e.g. perform disk unlock, load extra drivers, setup ZFS filesystem, and so on.

I don't have high hopes that this will change in mkinitcpio, but perhaps you could bring it up with booster (which copied the mkinitcpio hooks and removal scripts)

This is my personal preference, but consider switching to booster.

initramfs: booster - TPM2 support, way faster than mkinitcpio, autodiscovering root partition

Note I'm using booster, so assuming you're using the default mkinitcpio you probably want /boot/initramfs-linux.img. Also, don't forget to modify if your ESP isn't mounted at /boot like mine.

Booster initramfs generator supports TPM, Yubikey and Network binding so you can easily protect your data using the strategy you want.

GPT table detection has higher priority at booster code. But for some reason it does not identify your partition table as GPT. Filed a github bug for it https://github.com/anatol/booster/issues/119