0

I made a full encryption setup of Ubuntu 20.04 LTS according to this article. Due to it is highly recommended to add further passphrases to avoid loosing all data due to unavailability of the initial passphrase, I did so, by adding several passphrases using cryptsetup luksAddKey /dev/sda1 command. To be fully sure, that I have done all right, I checked for the validness of each passphrase by running cryptsetup luksOpen --test-passphrase /dev/sda1 and all passphrases passed the test successfully.

The problem is that while booting and trying to unlock the master key (GPT) I can use only the first entered passphrase. Others are not working, while they are OK if checking it after system load by using cryptsetup luksOpen --test-passphrase /dev/sda1.

Are there any known issues regarding this have been ever heard before or maybe there are some things that were our of my scope?

UPDATE:

  1. There are no any strings within my /etc/crypttab file except of those, mentioned in the HOWTO article. Here they are:
LUKS_BOOT UUID=<UUID-VALUE> /etc/luks/boot_os.keyfile luks,discard
sda5_crypt UUID=<UUID-VALUE> /etc/luks/boot_os.keyfile luks,discard
  1. According to systemd crypttab manual, if no key-slot option is used, then:

The default is to try all key slots in sequential order.

But for some reason this doesn't work.

2
  • Are you sure the key-slot option does not appear in your /etc/crypttab? It can produce the result you are observing. Unfortunately I'm unable to check whether that option is added by default to the initramfs of a real Ubuntu installation (when not specified in crypttab).
    – fra-san
    Apr 6, 2021 at 8:24
  • @fra-san, Nope. Only the following strings are in /etc/crypttab: LUKS_BOOT UUID=<SOME-UUID> /etc/luks/boot_os.keyfile luks,discard and sda5_crypt UUID=<SOME-UUID> /etc/luks/boot_os.keyfile luks,discard As described in HOWTO article (see my initial post). Apr 6, 2021 at 9:23

1 Answer 1

1

It seems that actually all passphrases work as they should. BUT the point was that response time from the first (initial) passphrase (about 5-7 sec) is significantly lower than the one from the rest of passphrases from the list. The most amusing thing here is that for all passphrases starting from the second one, the response time - the time from pressing the Enter button after entering a passphrase up to the moment the system actually starts - is about 25-35 (!) seconds. The root cause for such behavior is unknown. The main reason, why the initial question has been arisen, that I didn't wait such long time for system start and mistakenly thought that passphrases didn't work at all.

3
  • Slots are deliberately encrypted in a way that is computationally slow to decrypt. This slows down brute force decryption attempts. It can be configured with --iter-time ( see here ) when adding a slot. It can also be very different on different machines. So if you add a slot on one fast machine it can be very slow to use on another. Apr 6, 2021 at 22:45
  • @PhilipCouling, actually the machine itself and disk image (I use virtual machine) were and still are the same. I aware, that in case of moving virtual image (or physical disks) to a separate machine, computational resources could differ and fully depend on CPU/Mem/DiskSpeed(?) resources of each of them. Apr 7, 2021 at 13:10
  • in that case it does seem odd that you've succeeded in creating a 25-35 second slot on the same machine without knowingly waiting as long to create the slot and apparently without requesting it with -i or --iter-time. Apr 7, 2021 at 13:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .