I’ve recently set up OpenSUSE Slowroll as I’ve only read good things about OpenSUSE for a while and the concept of Slowroll warms my heart. I used the latest ISO to install, as described here: Portal:Slowroll - openSUSE Wiki
I went with all defaults for the file system, with LVM and full-disk encryption. Now to my question. On boot I’m obviously facing the master key decryption with the prompt Enter passphrase for hd0, gpt2 (UUID):.
I noticed that the decryption process (prompt Attempting to decrypt master key... takes noticeably longer, in comparison to Debians full-disk encryption (lvm, luks, ext4), but that doesn’t bug me too much. However, after entering the wrong password just once here, I’m dropped in to a grub bash-like prompt. Decryption works just fine, if I don’t mistype.
To my actual question:
Is that the expected scenario, when mistyping the decryption password?
How can I adjust the system to allow multiple tries?
On my current desktop system, I have a separate unencrypted “/boot” and an encrypted LVM. I’m using ext4.
The decryption is pretty fast. And if I mistype, I’m given another chance to get it right. And I should mention that I see the grub menu before I am asked for the encryption key.
On another system, I do not have a separate unencrypted “/boot”. On that system, I’m asked for the encryption key before I see the grub menu. That’s because grub has to decrypt to get at the menu. And it is slower in handling the decryption. That’s because grub is using only BIOS services for the I/O. And if I mistype, then I’m dropped to a grub command line. I guess grub doesn’t have recovery options built in. When that happens, I use CTRL-ALT-DEL and then start over.
In summary: Encryption handled be the kernel is fast and efficient. But when it is handled by grub, it is a lot slower and less efficient.
When using “btrfs”, it is recommended to not have a separate “/boot” partition. So that leaves you with grub doing the initial handling of the crypt.
You cannot, it is hardcoded in grub2. The current upstream grub2 allows three tries. You may consider openSUSE bug report asking for inclusion of this patch.
Alternative is to use grub2-bls or systemd-boot which store kernel and initrd on ESP.
Decryption does not use I/O or BIOS services. But grub2 is compiled for the most generic x86 CPU (it is still i386) and so does not use any optimizations available in the later models, nor does it have any low level handcrafted assembler code. Time is mostly spent computing PBKDF. Lowering the number of rounds has dramatic impact on the time needed to complete it.
Fascinating. Thank you for your responses. Seems like I’ve previously only dealt with systems, that modify this behavior or implement another method.
I didn’t pay much attention to the defaults during the installation process, but I’ll just reinstall Slowroll, to see how exactly the full-disk encryption is set up here, so I understand it better. Testing a new distro, I usually go with all defaults, as I assume this to be the expected way.
I reckon I will just have to be a bit more patient with my clumsy typing then.
Instead of reinstalling the system, there is an alternative path that is about reducing a cryptography parameter to speed up decryption. That also means, in this case, reducing the security level of your installation.
So you will have to choose a value between the default one, which is painfully slow and may provide a security level way too high for your needs, and a lower value that is high enough to provide an acceptable security level while being not too painful.
A citation from the RFC-8018 relative to this cryptography parameter:
Choosing a reasonable value for the iteration count depends on environment and circumstances, and varies from application to application. This document follows the recommendations made in FIPS Special Publication 800-132 [NISTSP132], which says:
The iteration count shall be selected as large as possible, as long as the time required to generate the key using the entered password is acceptable for the users. […] A minimum iteration count of 1,000 is recommended. For especially critical keys, or for very powerful systems or systems where user-perceived performance is not critical, an iteration count of 10,000,000 may be appropriate.
Thank you for the suggestion. I don’t mind the slow decryption, I was just noting that that caught my eye. The question was mainly about the number of attempts when trying to decrypt.