The only thing I can think of is the LUKS version used to create the container.
I don’t know exactly where Calamares or Grub is on this, but I recently learned grub should have been improved as to being able to use LUKS2 containers.
Unless something has changed recently - within the past months - I believe a Calamares install defaults to use luks version 1.
The defaults for a luks container - taken from cryptsetup --help
Default compiled-in key and passphrase parameters:
Maximum keyfile size: 8192kB, Maximum interactive passphrase length 512 (characters)
Default PBKDF for LUKS1: pbkdf2, iteration time: 2000 (ms)
Default PBKDF for LUKS2: argon2id
Iteration time: 2000, Memory required: 1048576kB, Parallel threads: 4
Default compiled-in device cipher parameters:
loop-AES: aes, Key 256 bits
plain: aes-cbc-essiv:sha256, Key: 256 bits, Password hashing: ripemd160
LUKS: aes-xts-plain64, Key: 256 bits, LUKS header hashing: sha256, RNG: /dev/urandom
LUKS: Default keysize with XTS mode (two internal keys) will be doubled.
Because every system is different there is no one-size-fits-all answer.
If you haven’t done so yet - you should really take a look at the Arch Wiki pages on encryption. This link jumps into the section on using cryptsetup
The man page is also very informative
benchmark <options>
Benchmarks ciphers and KDF (key derivation function). Without parameters, it tries to measure few common configurations.
To benchmark other ciphers or modes, you need to specify --cipher and --key-size options or --hash for KDF test.
NOTE: This benchmark is using memory only and is only informative. You cannot directly predict real storage encryption
speed from it.
For testing block ciphers, this benchmark requires kernel userspace crypto API to be available (introduced in Linux ker‐
nel 2.6.38). If you are configuring kernel yourself, enable "User-space interface for symmetric key cipher algorithms"
in "Cryptographic API" section (CRYPTO_USER_API_SKCIPHER .config option).
<options> can be [--cipher, --key-size, --hash].
The result of running cryptsetup benchmark on my system
➜ ~ cryptsetup benchmark
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1 2202890 iterations per second for 256-bit key
PBKDF2-sha256 2792479 iterations per second for 256-bit key
PBKDF2-sha512 1949026 iterations per second for 256-bit key
PBKDF2-ripemd160 1134822 iterations per second for 256-bit key
PBKDF2-whirlpool 858081 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 1484,5 MiB/s 4573,7 MiB/s
serpent-cbc 128b 124,5 MiB/s 962,7 MiB/s
twofish-cbc 128b 284,2 MiB/s 516,4 MiB/s
aes-cbc 256b 1144,3 MiB/s 3645,9 MiB/s
serpent-cbc 256b 128,2 MiB/s 963,7 MiB/s
twofish-cbc 256b 290,6 MiB/s 520,3 MiB/s
aes-xts 256b 4394,8 MiB/s 4427,0 MiB/s
serpent-xts 256b 829,7 MiB/s 846,3 MiB/s
twofish-xts 256b 482,9 MiB/s 487,8 MiB/s
aes-xts 512b 3620,4 MiB/s 3612,7 MiB/s
serpent-xts 512b 842,3 MiB/s 847,0 MiB/s
twofish-xts 512b 486,4 MiB/s 487,6 MiB/s
Another option would be to utiliise the disk device’s encryption engine.
Even that could have other implications as implied in this topic on StackExchange/Security
I don’t know how to do it but from I can see from a few searches it uses TPM and I recall something about TPM being linked to Secure Boot - and this is where it get hairy on Archbased systems.
- Using Hardware Encryption on NVME SSD used as the boot device - Security/StackExchange
- https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot
You should also know that the nature of flash devices makes it difficult to ensure that data is never recoverable by forencic tools.
I read an academic paper on how to reliably erase data from flash based device - it is quite interesting.