Re: Slow unlock of the LUKS device at boot

Arno Wagner <[email protected]>
Newsgroups dev.linux.lists.cryptsetup
Message-ID <[email protected]>
Hi Lamy,

if you created the slow-to-unlock LUKS container on this
device and with default parameters, then there seems to be 
some bug or configuration problem at play. 

I have never used keyfiles (except for some tests),
so I do not know what it could be.

Regards,
Arno


On Tue, Nov 29, 2022 at 21:19:50 CET, Lamy Geier wrote:
> # Observation
> 
> For the slow partition (that uses LUKS2 and has LVM) takes about 6 minutes
> to test passphrase as follows and returns a warning "No usable token is
> available."
> 
> ```bash
> sudo cryptsetup -v open --test-passphrase --type luks /dev/nvme0n1p5
> --key-file /etc/luks/boot_os.keyfile
> sudo cryptsetup -v open --test-passphrase --type luks /dev/nvme0n1p5
> ```
> 
> For the boot partition (LUKS1), which used the same passphrase and keyfile
> as the above partition it takes just 5 seconds to test passphrase
> 
> 
> ```bash
> sudo cryptsetup -v open --test-passphrase --type luks /dev/nvme0n1p1
> --key-file /etc/luks/boot_os.keyfile
> sudo cryptsetup -v open --test-passphrase --type luks /dev/nvme0n1p1
> ```
> 
> ---
> 
> Also, I did cryptsetup benchmark as follows
> 
>   ``` bash
>   $ cryptsetup benchmark
>   # Tests are approximate using memory only (no storage IO).
>   PBKDF2-sha1      2631307 iterations per second for 256-bit key
>   PBKDF2-sha256    5637505 iterations per second for 256-bit key
>   PBKDF2-sha512    2118335 iterations per second for 256-bit key
>   PBKDF2-ripemd160 1115506 iterations per second for 256-bit key
>   PBKDF2-whirlpool 1006310 iterations per second for 256-bit key
>   argon2i       9 iterations, 1048576 memory, 4 parallel threads (CPUs) for
> 256-bit key (requested 2000 ms time)
>   argon2id      9 iterations, 1048576 memory, 4 parallel threads (CPUs) for
> 256-bit key (requested 2000 ms time)
>   #     Algorithm |       Key |      Encryption |      Decryption
>           aes-cbc        128b      1727.7 MiB/s      6931.8 MiB/s
>       serpent-cbc        128b       116.2 MiB/s       868.9 MiB/s
>       twofish-cbc        128b       252.9 MiB/s       566.7 MiB/s
>           aes-cbc        256b      1313.0 MiB/s      5684.8 MiB/s
>       serpent-cbc        256b       120.3 MiB/s       867.2 MiB/s
>       twofish-cbc        256b       257.5 MiB/s       563.5 MiB/s
>           aes-xts        256b      5342.5 MiB/s      5333.8 MiB/s
>       serpent-xts        256b       748.8 MiB/s       783.1 MiB/s
>       twofish-xts        256b       517.7 MiB/s       530.6 MiB/s
>           aes-xts        512b      4779.9 MiB/s      4819.2 MiB/s
>       serpent-xts        512b       756.1 MiB/s       779.9 MiB/s
>       twofish-xts        512b       521.5 MiB/s       529.2 MiB/s
>   ```
> 
> 
> 
> - Is the warning responsible for this slow behavior: "No usable token is
> available." Or can you suggest if I should tweak some key parameters or
> change the order of keys in keyslots.
> 
> 
> -- 
> Thanks and Regards
> 
> Lamy

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: [email protected]
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.