How do I unlock my LUKS disks on Ubuntu 26.04 from a Live USB (if my computer is ubootable)?

[peterwhite23]

Sorry, I should have been more clear:

$ snap-tpmctl get-luks-key --escaped
Enter recovery key: *****-*****-*****-*****-*****-*****-*****-*****
"kLR\r\x95c#}\x05\xcd\xc1\x8b\xb9v\x81\xac"
$ printf "kLR\r\x95c#}\x05\xcd\xc1\x8b\xb9v\x81\xac" >/tmp/keyfile
$ sudo cryptsetup luksOpen --test-passphrase --key-file=/tmp/keyfile /dev/disk/by-id/ata-QEMU_HARDDISK_QM00003-part5 && echo SUCCESS
SUCCESS

I was able to emulate get-luks-key by this:

printf "%.4x" $(sed -E -e 's/-/ /g' -e 's/\b0*//g' <recovery-key.txt) | sed -E 's/([0-9a-f]{2})([0-9a-f]{2})/\2\1/g' | xxd -r -p

(sed -E 's/\b0*//g' to strip leading 0’s so as to not accidentally have the number interpreted as octal)
[EDIT: trimmed down version; xxd does not allow concatenating option like -rp, which is why p was ignored and thus the first byte was interpreted as offset; removed redundat tr – incorporated into sed command]

[paddylandau]

Thank you!

By the way, you don’t need sudo with snap-tpmctl when getting the LUKS key, because it’s merely manipulating strings.

[peterwhite23]

As for the length of the recovery key, I think it might be misleading. When you look at the luksDump output, you’ll find that all slots are populated with 512 bit keys. They are derived by PBKDF2 from the passphrase, which is just a raw byte string in case of the recovery key. Key derivation functions add extra computational costs — it takes a moment for --test-passphrase to return —, so brute-forcing a recovery key is probably equally or even more computationally expensive than doing the same with the 512 bits volume key.

At least that’s what I came up with for an explanation.

[peterwhite23]

Replying to myself to confirm that this is what happens. The cryptsetup FAQ has all the info — great (re)read, BTW.

Unlocking with Key File

• 2.10 How do I read a LUKS slot key from file?

What you really do here is to read a passphrase from file, just as you would with manual entry of a passphrase for a key-slot.
[…]
To supply a key from file to any LUKS command, use the --key-file option, e.g. like this:

    cryptsetup luksOpen --key-file keyfile /dev/loop0 e1

Salt by the Shovel

• 5.8 What is a “salt”?

A salt is a random key-grade value added to the passphrase before it is processed. It is not kept secret. The reason for using salts is as follows: If an attacker wants to crack the password for a single LUKS container, then every possible passphrase has to be tried. Typically an attacker will not try every binary value, but will try words and sentences from a dictionary.

If an attacker wants to attack several LUKS containers with the same dictionary, then a different approach makes sense: Compute the resulting slot-key for each dictionary element and store it on disk. Then the test for each entry is just the slow unlocking with the slot key (say 0.00001 sec) instead of calculating the slot-key first (1 sec). For a single attack, this does not help. But if you have more than one container to attack, this helps tremendously, also because you can prepare your table before you even have the container to attack! The calculation is also very simple to parallelize. You could, for example, use the night-time unused CPU power of your desktop PCs for this.

This is where the salt comes in. If the salt is combined with the passphrase (in the simplest form, just appended to it), you suddenly need a separate table for each salt value. With a reasonably-sized salt value (256 bit, e.g.) this is quite infeasible.

(emphasis added)
Note how key derivation takes about 1 sec by design — the number of iterations for PBKDF is chosen at creation time, depending on the target machine —, to slow down brute force attacks. So now, thanks to the salt, the attacker cannot make any use of rainbow tables and needs to go through the key derivation function on every try, so 1 sec per, which is an eternity: 2¹²⁸ seconds are ~10³¹ years; or they’d need 2²⁵⁶ rainbow tables, because the slot keys are rather salty — 32 bytes (256 bits). Even if an attacker had 1000x the computing power of your machine, to get through the iterations 1000x quicker (see 5.10), it’d take them 10²⁸ (CPU) years — or, IOW, if they had 100,000 trillion trillion CPU’s, each 1000x as fast as yours, to do it in parallel, they’d pull it off in one year.

About Entropy

• 5.9 Is LUKS secure with a low-entropy (bad) passphrase?

Short answer: yes. Do not use a low-entropy passphrase.

Note: For LUKS2, protection for bad passphrases is a bit better due to the use of Argon2, but that is only a gradual improvement.
…

It’s probably worth noting that the TPM/FDE setup of Ubuntu doesn’t use Argon2 but PDKBF2 (see 5.11).

[5.9 ctd.]
…
Still, if you want good security, a high-entropy passphrase is the only option. For example, a low-entropy passphrase can never be considered secure against a TLA-level (Three Letter Agency level, i.e. government-level) attacker, no matter what tricks are used in the key-derivation function. Use at least 64 bits for secret stuff. That is 64 characters of English text (but only if randomly chosen) or a combination of 12 truly random letters and digits.

(emphasis added)

By that standard, Ubuntu’s 128 bit recovery key is extremely rich in entropy.

From memory, I also think that 128 bit symmetric keys are still considered pretty secure. Or let’s just do the math; suppose we only had a 128 bit volume (master) key; brute-forcing it cannot be slowed down by PDKDF, since the attacker only needs to try decrypting stuff and see if the output is not obvious gibberish. Suppose further that a single attempt only takes 1 microsecond; that only shifts the decimal point 6 digits to the left, so the attacker would now only need 0.1 trillion trillion machines to do it in one year — : any day now…

[paddylandau]

Peter, that was informative and interesting, thank you!

I always knew that a salt was important, but I hadn’t bothered to find out why. Now I know.

@peterwhite23

It’s probably worth noting that the TPM/FDE setup of Ubuntu doesn’t use Argon2 but PDKBF2

According to this documentation, 26.04 uses Argon2, not PDKBF2; unless you use FIPS mode.

However, I checked this on my installation. It uses PBKDF2, not Argon2, as you correctly stated.

$ lsblk --fs | grep -F crypto_LUKS
├─sda4  crypto_LUKS 2  ubuntu-save-enc [redacted]
└─sda5  crypto_LUKS 2  ubuntu-data-enc [redacted]

sda4 is the “save” partition, and sda5 the “data” partition.

$ sudo cryptsetup luksDump /dev/sda4 | grep -Fi argon
$ sudo cryptsetup luksDump /dev/sda4 | grep -F PBKDF:
	PBKDF:      pbkdf2
	PBKDF:      pbkdf2
	PBKDF:      pbkdf2

The same for sda5.

Apparently, this is because TPM-backed encryption uses “PBKDF2 for maximum system initialization speed and stability,” and doesn’t need the higher security of Argon2 because “a TPM-backed setup relies on the hardware’s built-in anti-hammering (rate-limiting) logic to protect against brute-force attacks. The physical TPM chip itself prevents quick guesses.”

So, it’s all good.

I have been learning so much in the past few days!