cryptsetup.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
* Slow unlock of the LUKS device at boot
@ 2022-11-29 19:50 Lamy Geier
  2022-11-29 20:02 ` Lamy Geier
                   ` (2 more replies)
  0 siblings, 3 replies; 6+ messages in thread
From: Lamy Geier @ 2022-11-29 19:50 UTC (permalink / raw)
  To: cryptsetup

My boot partition (/dev/nvme0n1p1) is using LUKS1. And another partition 
(/dev/nvme0n1p5) is using LUKS2 which has LVM with root volume,  home 
volume and swap volumes. Both of these have same passphrase.

I am using Grub. While booting I enter the passphrase to unlock the boot 
partition. To automatically unlock the partition with LVM volumes, I 
have created a keyfile (boot_os.keyfile) which is stored in the device 
itself, which is used to unlock it. I have created it as follows:

```bash
# echo "KEYFILE_PATTERN=/etc/luks/*.keyfile" >> 
/etc/cryptsetup-initramfs/conf-hook
# echo "UMASK=0077" >> /etc/initramfs-tools/initramfs.conf
```

- Create a randomised key-file of 4096 bits (512 bytes), secure it, and 
add it to the LUKS volumes (Man-pages for dd chmod):

```bash
# mkdir /etc/luks
# dd if=/dev/urandom of=/etc/luks/boot_os.keyfile bs=512 count=1
1+0 records in u=rx,go-rwx /etc/luks
1+0 records out
512 bytes (0.5 kB, 0.5 KiB) copied, 0.0002368 s, 17.3 MB/s

# chmod u=rx,go-rwx /etc/luks
# chmod u=r,go-rwx /etc/luks/boot_os.keyfile

# cryptsetup luksAddKey /dev/nvme0n1p1 /etc/luks/boot_os.keyfile
Enter any existing passphrase:

# cryptsetup luksAddKey /dev/nvme0n1p5 /etc/luks/boot_os.keyfile
Enter any existing passphrase:
```

Add the keys to the crypttab:

```bash
# echo "LUKS_BOOT UUID=$(blkid -s UUID -o value ${DEVP}1) 
/etc/luks/boot_os.keyfile luks,discard" >> /etc/crypttab
# echo "${DM}5_crypt UUID=$(blkid -s UUID -o value ${DEVP}5) 
/etc/luks/boot_os.keyfile luks,discard" >> /etc/crypttab
```

The above is taken from: [Full_Disk_Encryption_Howto_2019 - Community 
Help 
Wiki](https://help.ubuntu.com/community/Full_Disk_Encryption_Howto_2019#Post-Installation_Steps)

---

# Issue

The boot partition unlocks very quickly (5 seconds) but the LVM volume 
takes about 6 minutes to unlock.

Following are the key dump of both these partitions. With the keyslot 0 
in both being the same passphrase, and keyslot 1 being the key file:

```
$ sudo cryptsetup luksDump /dev/nvme0n1p1
Place your right index finger on the fingerprint reader
LUKS header information for /dev/nvme0n1p1

Version:        1
Cipher name:    aes
Cipher mode:    xts-plain64
Hash spec:      sha256
Payload offset: 4096
MK bits:        512
MK digest:      ec 22 27 de c1 ef 40 0f a5 cf 37 d3 96 5c d5 b2 6e c8 dd 90
MK salt:        62 1a 05 81 ba 60 3b 0d b1 8a 9f f0 04 98 27 54
                 06 b6 8d 72 53 23 09 47 ea 5f 80 1d d7 c5 ca 50
MK iterations:  305173
UUID:           586de9a0-14c7-40d7-b721-7fdba2e3b184

Key Slot 0: ENABLED
         Iterations:             1000
         Salt:                   4b f1 99 85 84 a5 00 d6 a4 e8 e1 07 35 
b4 da a1
                                 fc 97 59 5f 4c f8 e1 9b 49 71 29 af e5 
56 b1 19
         Key material offset:    8
         AF stripes:             4000
Key Slot 1: ENABLED
         Iterations:             4848906
         Salt:                   91 70 85 49 f3 31 e8 53 1f 39 aa 6d 7a 
3e 84 de
                                 e4 3f bd 3d 65 bf f6 b1 e6 8c 15 fa 34 
b9 e3 e0
         Key material offset:    512
         AF stripes:             4000
```

```
$ sudo cryptsetup luksDump /dev/nvme0n1p5
LUKS header information
Version:        2
Epoch:          10
Metadata area:  16384 [bytes]
Keyslots area:  16744448 [bytes]
UUID:           ee8854e8-54f6-4f7b-b326-02fdee357d0e
Label:          (no label)
Subsystem:      (no subsystem)
Flags:          (no flags)

Data segments:
   0: crypt
         offset: 16777216 [bytes]
         length: (whole device)
         cipher: aes-xts-plain64
         sector: 512 [bytes]

Keyslots:
   0: luks2
         Key:        512 bits
         Priority:   normal
         Cipher:     aes-xts-plain64
         Cipher key: 512 bits
         PBKDF:      argon2id
         Time cost:  1000
         Memory:     1048576
         Threads:    4
         Salt:       93 17 44 b3 39 82 ab 0c 20 81 0b 2b 8d 38 b1 42
                     57 53 bf ad 11 5c d5 f5 8e 42 47 45 21 73 74 84
         AF stripes: 4000
         AF hash:    sha256
         Area offset:806912 [bytes]
         Area length:258048 [bytes]
         Digest ID:  0
   1: luks2
         Key:        512 bits
         Priority:   normal
         Cipher:     aes-xts-plain64
         Cipher key: 512 bits
         PBKDF:      argon2id
         Time cost:  9
         Memory:     1048576
         Threads:    4
         Salt:       b9 84 4c ee e5 38 5d 3e 7e c3 1f 12 b3 6c 42 9b
                     a4 61 7c f8 12 55 99 25 fe d6 76 15 4b 65 11 66
         AF stripes: 4000
         AF hash:    sha256
         Area offset:32768 [bytes]
         Area length:258048 [bytes]
         Digest ID:  0
Tokens:
Digests:
   0: pbkdf2
         Hash:       sha256
         Iterations: 305529
         Salt:       db 22 26 2b b0 dc 12 19 a1 e1 13 d2 98 92 43 2c
                     d3 e6 f2 da 9a 08 e5 a3 56 42 f5 e7 b0 89 bc 75
         Digest:     bb e0 6e 95 50 0c 86 ce 3a 1b bd 7e 7b da 16 ba
                     84 c7 9a 41 a2 09 9c b1 a5 a6 3d 80 31 5a 27 64
```

# Help request?

Can you please suggest if I need to change the order of the keys or 
change the iteration time cost or any other parameter to make my LVM 
volume to unlock faster?

Note: My passphrase has high entropy and the keyfile also has high 
entropy as it is generated with random numbers.


-- 
Thanks and Regards

Lamy

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Slow unlock of the LUKS device at boot
  2022-11-29 19:50 Slow unlock of the LUKS device at boot Lamy Geier
@ 2022-11-29 20:02 ` Lamy Geier
  2022-11-29 20:19 ` Lamy Geier
  2022-12-01 14:40 ` Ondrej Kozina
  2 siblings, 0 replies; 6+ messages in thread
From: Lamy Geier @ 2022-11-29 20:02 UTC (permalink / raw)
  To: cryptsetup

Also, do you suggest changing the order of keys in the keyslot for the 
partition with LVM volume?

On 2022-11-29 20:50, Lamy Geier wrote:
> My boot partition (/dev/nvme0n1p1) is using LUKS1. And another partition 
> (/dev/nvme0n1p5) is using LUKS2 which has LVM with root volume,  home 
> volume and swap volumes. Both of these have same passphrase.
> 
> I am using Grub. While booting I enter the passphrase to unlock the boot 
> partition. To automatically unlock the partition with LVM volumes, I 
> have created a keyfile (boot_os.keyfile) which is stored in the device 
> itself, which is used to unlock it. I have created it as follows:
> 
> ```bash
> # echo "KEYFILE_PATTERN=/etc/luks/*.keyfile" >> 
> /etc/cryptsetup-initramfs/conf-hook
> # echo "UMASK=0077" >> /etc/initramfs-tools/initramfs.conf
> ```
> 
> - Create a randomised key-file of 4096 bits (512 bytes), secure it, and 
> add it to the LUKS volumes (Man-pages for dd chmod):
> 
> ```bash
> # mkdir /etc/luks
> # dd if=/dev/urandom of=/etc/luks/boot_os.keyfile bs=512 count=1
> 1+0 records in u=rx,go-rwx /etc/luks
> 1+0 records out
> 512 bytes (0.5 kB, 0.5 KiB) copied, 0.0002368 s, 17.3 MB/s
> 
> # chmod u=rx,go-rwx /etc/luks
> # chmod u=r,go-rwx /etc/luks/boot_os.keyfile
> 
> # cryptsetup luksAddKey /dev/nvme0n1p1 /etc/luks/boot_os.keyfile
> Enter any existing passphrase:
> 
> # cryptsetup luksAddKey /dev/nvme0n1p5 /etc/luks/boot_os.keyfile
> Enter any existing passphrase:
> ```
> 
> Add the keys to the crypttab:
> 
> ```bash
> # echo "LUKS_BOOT UUID=$(blkid -s UUID -o value ${DEVP}1) 
> /etc/luks/boot_os.keyfile luks,discard" >> /etc/crypttab
> # echo "${DM}5_crypt UUID=$(blkid -s UUID -o value ${DEVP}5) 
> /etc/luks/boot_os.keyfile luks,discard" >> /etc/crypttab
> ```
> 
> The above is taken from: [Full_Disk_Encryption_Howto_2019 - Community 
> Help 
> Wiki](https://help.ubuntu.com/community/Full_Disk_Encryption_Howto_2019#Post-Installation_Steps)
> 
> ---
> 
> # Issue
> 
> The boot partition unlocks very quickly (5 seconds) but the LVM volume 
> takes about 6 minutes to unlock.
> 
> Following are the key dump of both these partitions. With the keyslot 0 
> in both being the same passphrase, and keyslot 1 being the key file:
> 
> ```
> $ sudo cryptsetup luksDump /dev/nvme0n1p1
> Place your right index finger on the fingerprint reader
> LUKS header information for /dev/nvme0n1p1
> 
> Version:        1
> Cipher name:    aes
> Cipher mode:    xts-plain64
> Hash spec:      sha256
> Payload offset: 4096
> MK bits:        512
> MK digest:      ec 22 27 de c1 ef 40 0f a5 cf 37 d3 96 5c d5 b2 6e c8 dd 90
> MK salt:        62 1a 05 81 ba 60 3b 0d b1 8a 9f f0 04 98 27 54
>                  06 b6 8d 72 53 23 09 47 ea 5f 80 1d d7 c5 ca 50
> MK iterations:  305173
> UUID:           586de9a0-14c7-40d7-b721-7fdba2e3b184
> 
> Key Slot 0: ENABLED
>          Iterations:             1000
>          Salt:                   4b f1 99 85 84 a5 00 d6 a4 e8 e1 07 35 
> b4 da a1
>                                  fc 97 59 5f 4c f8 e1 9b 49 71 29 af e5 
> 56 b1 19
>          Key material offset:    8
>          AF stripes:             4000
> Key Slot 1: ENABLED
>          Iterations:             4848906
>          Salt:                   91 70 85 49 f3 31 e8 53 1f 39 aa 6d 7a 
> 3e 84 de
>                                  e4 3f bd 3d 65 bf f6 b1 e6 8c 15 fa 34 
> b9 e3 e0
>          Key material offset:    512
>          AF stripes:             4000
> ```
> 
> ```
> $ sudo cryptsetup luksDump /dev/nvme0n1p5
> LUKS header information
> Version:        2
> Epoch:          10
> Metadata area:  16384 [bytes]
> Keyslots area:  16744448 [bytes]
> UUID:           ee8854e8-54f6-4f7b-b326-02fdee357d0e
> Label:          (no label)
> Subsystem:      (no subsystem)
> Flags:          (no flags)
> 
> Data segments:
>    0: crypt
>          offset: 16777216 [bytes]
>          length: (whole device)
>          cipher: aes-xts-plain64
>          sector: 512 [bytes]
> 
> Keyslots:
>    0: luks2
>          Key:        512 bits
>          Priority:   normal
>          Cipher:     aes-xts-plain64
>          Cipher key: 512 bits
>          PBKDF:      argon2id
>          Time cost:  1000
>          Memory:     1048576
>          Threads:    4
>          Salt:       93 17 44 b3 39 82 ab 0c 20 81 0b 2b 8d 38 b1 42
>                      57 53 bf ad 11 5c d5 f5 8e 42 47 45 21 73 74 84
>          AF stripes: 4000
>          AF hash:    sha256
>          Area offset:806912 [bytes]
>          Area length:258048 [bytes]
>          Digest ID:  0
>    1: luks2
>          Key:        512 bits
>          Priority:   normal
>          Cipher:     aes-xts-plain64
>          Cipher key: 512 bits
>          PBKDF:      argon2id
>          Time cost:  9
>          Memory:     1048576
>          Threads:    4
>          Salt:       b9 84 4c ee e5 38 5d 3e 7e c3 1f 12 b3 6c 42 9b
>                      a4 61 7c f8 12 55 99 25 fe d6 76 15 4b 65 11 66
>          AF stripes: 4000
>          AF hash:    sha256
>          Area offset:32768 [bytes]
>          Area length:258048 [bytes]
>          Digest ID:  0
> Tokens:
> Digests:
>    0: pbkdf2
>          Hash:       sha256
>          Iterations: 305529
>          Salt:       db 22 26 2b b0 dc 12 19 a1 e1 13 d2 98 92 43 2c
>                      d3 e6 f2 da 9a 08 e5 a3 56 42 f5 e7 b0 89 bc 75
>          Digest:     bb e0 6e 95 50 0c 86 ce 3a 1b bd 7e 7b da 16 ba
>                      84 c7 9a 41 a2 09 9c b1 a5 a6 3d 80 31 5a 27 64
> ```
> 
> # Help request?
> 
> Can you please suggest if I need to change the order of the keys or 
> change the iteration time cost or any other parameter to make my LVM 
> volume to unlock faster?
> 
> Note: My passphrase has high entropy and the keyfile also has high 
> entropy as it is generated with random numbers.
> 
> 

-- 
Thanks and Regards

Lamy

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Slow unlock of the LUKS device at boot
  2022-11-29 19:50 Slow unlock of the LUKS device at boot Lamy Geier
  2022-11-29 20:02 ` Lamy Geier
@ 2022-11-29 20:19 ` Lamy Geier
  2022-11-29 20:39   ` Arno Wagner
  2022-12-01 14:40 ` Ondrej Kozina
  2 siblings, 1 reply; 6+ messages in thread
From: Lamy Geier @ 2022-11-29 20:19 UTC (permalink / raw)
  To: cryptsetup

# 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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Slow unlock of the LUKS device at boot
  2022-11-29 20:19 ` Lamy Geier
@ 2022-11-29 20:39   ` Arno Wagner
  0 siblings, 0 replies; 6+ messages in thread
From: Arno Wagner @ 2022-11-29 20:39 UTC (permalink / raw)
  To: Lamy Geier; +Cc: cryptsetup

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: arno@wagner.name
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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Slow unlock of the LUKS device at boot
  2022-11-29 19:50 Slow unlock of the LUKS device at boot Lamy Geier
  2022-11-29 20:02 ` Lamy Geier
  2022-11-29 20:19 ` Lamy Geier
@ 2022-12-01 14:40 ` Ondrej Kozina
  2022-12-01 21:07   ` Arno Wagner
  2 siblings, 1 reply; 6+ messages in thread
From: Ondrej Kozina @ 2022-12-01 14:40 UTC (permalink / raw)
  To: cryptsetup; +Cc: Lamy Geier

On 29. 11. 22 20:50, Lamy Geier wrote:
> My boot partition (/dev/nvme0n1p1) is using LUKS1. And another partition
> (/dev/nvme0n1p5) is using LUKS2 which has LVM with root volume,  home
> volume and swap volumes. Both of these have same passphrase.
> 
> I am using Grub. While booting I enter the passphrase to unlock the boot
> partition. To automatically unlock the partition with LVM volumes, I
> have created a keyfile (boot_os.keyfile) which is stored in the device
> itself, which is used to unlock it. I have created it as follows:
> 
> ```bash
> # echo "KEYFILE_PATTERN=/etc/luks/*.keyfile" >>
> /etc/cryptsetup-initramfs/conf-hook
> # echo "UMASK=0077" >> /etc/initramfs-tools/initramfs.conf
> ```
> 
> - Create a randomised key-file of 4096 bits (512 bytes), secure it, and
> add it to the LUKS volumes (Man-pages for dd chmod):
> 
> ```bash
> # mkdir /etc/luks
> # dd if=/dev/urandom of=/etc/luks/boot_os.keyfile bs=512 count=1
> 1+0 records in u=rx,go-rwx /etc/luks
> 1+0 records out
> 512 bytes (0.5 kB, 0.5 KiB) copied, 0.0002368 s, 17.3 MB/s
> 
> # chmod u=rx,go-rwx /etc/luks
> # chmod u=r,go-rwx /etc/luks/boot_os.keyfile
> 
> # cryptsetup luksAddKey /dev/nvme0n1p1 /etc/luks/boot_os.keyfile
> Enter any existing passphrase:
> 
> # cryptsetup luksAddKey /dev/nvme0n1p5 /etc/luks/boot_os.keyfile
> Enter any existing passphrase:
> ```
> 
> Add the keys to the crypttab:
> 
> ```bash
> # echo "LUKS_BOOT UUID=$(blkid -s UUID -o value ${DEVP}1)
> /etc/luks/boot_os.keyfile luks,discard" >> /etc/crypttab
> # echo "${DM}5_crypt UUID=$(blkid -s UUID -o value ${DEVP}5)
> /etc/luks/boot_os.keyfile luks,discard" >> /etc/crypttab
> ```
> 
> The above is taken from: [Full_Disk_Encryption_Howto_2019 - Community
> Help
> Wiki](https://help.ubuntu.com/community/Full_Disk_Encryption_Howto_2019#Post-Installation_Steps)
> 
> ---
> 
> # Issue
> 
> The boot partition unlocks very quickly (5 seconds) but the LVM volume
> takes about 6 minutes to unlock.
> 
> Following are the key dump of both these partitions. With the keyslot 0
> in both being the same passphrase, and keyslot 1 being the key file:
> 
> ```
> $ sudo cryptsetup luksDump /dev/nvme0n1p1
> Place your right index finger on the fingerprint reader
> LUKS header information for /dev/nvme0n1p1
> 
> Version:        1
> Cipher name:    aes
> Cipher mode:    xts-plain64
> Hash spec:      sha256
> Payload offset: 4096
> MK bits:        512
> MK digest:      ec 22 27 de c1 ef 40 0f a5 cf 37 d3 96 5c d5 b2 6e c8 dd 90
> MK salt:        62 1a 05 81 ba 60 3b 0d b1 8a 9f f0 04 98 27 54
>                   06 b6 8d 72 53 23 09 47 ea 5f 80 1d d7 c5 ca 50
> MK iterations:  305173
> UUID:           586de9a0-14c7-40d7-b721-7fdba2e3b184
> 
> Key Slot 0: ENABLED
>           Iterations:             1000
>           Salt:                   4b f1 99 85 84 a5 00 d6 a4 e8 e1 07 35
> b4 da a1
>                                   fc 97 59 5f 4c f8 e1 9b 49 71 29 af e5
> 56 b1 19
>           Key material offset:    8
>           AF stripes:             4000
> Key Slot 1: ENABLED
>           Iterations:             4848906
>           Salt:                   91 70 85 49 f3 31 e8 53 1f 39 aa 6d 7a
> 3e 84 de
>                                   e4 3f bd 3d 65 bf f6 b1 e6 8c 15 fa 34
> b9 e3 e0
>           Key material offset:    512
>           AF stripes:             4000
> ```
> 
> ```
> $ sudo cryptsetup luksDump /dev/nvme0n1p5
> LUKS header information
> Version:        2
> Epoch:          10
> Metadata area:  16384 [bytes]
> Keyslots area:  16744448 [bytes]
> UUID:           ee8854e8-54f6-4f7b-b326-02fdee357d0e
> Label:          (no label)
> Subsystem:      (no subsystem)
> Flags:          (no flags)
> 
> Data segments:
>     0: crypt
>           offset: 16777216 [bytes]
>           length: (whole device)
>           cipher: aes-xts-plain64
>           sector: 512 [bytes]
> 
> Keyslots:
>     0: luks2
>           Key:        512 bits
>           Priority:   normal
>           Cipher:     aes-xts-plain64
>           Cipher key: 512 bits
>           PBKDF:      argon2id
>           Time cost:  1000
                         ^^^^
This is insane value for argon2 and it would explain your 6 minutes 
unlock time. Usually on my 2 years old laptop I get values in range 6-9 
iterations (Time cost) with 4 threads and 1GiB ram used when I let 
cryptsetup do the benchmark with default target time ~2 seconds. Are you 
sure you did not add --pbkdf-force-iterations parameter in your 
luksAddKey command earlier?

With regards
O.


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Slow unlock of the LUKS device at boot
  2022-12-01 14:40 ` Ondrej Kozina
@ 2022-12-01 21:07   ` Arno Wagner
  0 siblings, 0 replies; 6+ messages in thread
From: Arno Wagner @ 2022-12-01 21:07 UTC (permalink / raw)
  To: Ondrej Kozina; +Cc: cryptsetup, Lamy Geier

On Thu, Dec 01, 2022 at 15:40:15 CET, Ondrej Kozina wrote:
> On 29. 11. 22 20:50, Lamy Geier wrote:
[...]
> > Keyslots:
> >     0: luks2
> >           Key:        512 bits
> >           Priority:   normal
> >           Cipher:     aes-xts-plain64
> >           Cipher key: 512 bits
> >           PBKDF:      argon2id
> >           Time cost:  1000
>                         ^^^^
> This is insane value for argon2 and it would explain your 6 minutes unlock
> time. Usually on my 2 years old laptop I get values in range 6-9 iterations
> (Time cost) with 4 threads and 1GiB ram used when I let cryptsetup do the
> benchmark with default target time ~2 seconds. Are you sure you did not add
> --pbkdf-force-iterations parameter in your luksAddKey command earlier?
> 
> With regards
> O.

That seems to be it. So misconfiguration after all as I suspected.

Regards,
Arno 

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
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

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2022-12-01 21:07 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-11-29 19:50 Slow unlock of the LUKS device at boot Lamy Geier
2022-11-29 20:02 ` Lamy Geier
2022-11-29 20:19 ` Lamy Geier
2022-11-29 20:39   ` Arno Wagner
2022-12-01 14:40 ` Ondrej Kozina
2022-12-01 21:07   ` Arno Wagner

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).