CryptSetup

Advanced Cryptsetup Configuration for Post-Quantum Resilience

Introduction

As quantum computing evolves, traditional cryptographic systems—especially those based on RSA, DH, and ECC—face the risk of being broken. While disk encryption tools like cryptsetup with LUKS are not directly based on public-key cryptography, ensuring that your configuration is hardened against both classical and quantum threats is increasingly important.

This guide outlines how to inspect and configure cryptsetup to maximize security, including optional post-quantum considerations.

Inspecting Your Existing LUKS Partition

To examine the current cryptographic parameters of an existing LUKS partition:

sudo cryptsetup luksDump /dev/sdX

Replace /dev/sdX with your actual device (e.g., /dev/nvme0n1p2).

Key sections to note in the output:

• Cipher: e.g., aes-xts-plain64
• Key size: 256 or 512 bits (AES-128 or AES-256 in XTS mode)
• PBKDF: pbkdf2 or argon2id
• Hash: e.g., sha256, sha3-512

To inspect a mapped (unlocked) device:

sudo cryptsetup status my-mapped-device

Can I Change the Cipher or Key Size Without Formatting?

No. Parameters like cipher, key-size, and hash are defined during the initial luksFormat and cannot be changed later. To use a stronger cipher or key size, you must backup, reformat, and restore your data.

What Can Be Changed Without Formatting

You can add a new keyslot using a more secure KDF (e.g., argon2id):

sudo cryptsetup luksAddKey --pbkdf=argon2id /dev/sdX

With full control over KDF parameters:

sudo cryptsetup luksAddKey \
  --pbkdf=argon2id \
  --pbkdf-memory=1048576 \
  --pbkdf-parallel=4 \
  --pbkdf-time=5000 \
  /dev/sdX

Then optionally remove a weaker keyslot:

sudo cryptsetup luksKillSlot /dev/sdX 0

You can also convert LUKS1 to LUKS2 (experimental):

sudo cryptsetup convert --type luks2 /dev/sdX

Recommended Secure Configuration

To create a highly secure LUKS2 partition:

cryptsetup luksFormat /dev/sdX \
  --type luks2 \
  --cipher aes-xts-plain64 \
  --key-size 512 \
  --hash sha3-512 \
  --pbkdf argon2id \
  --iter-time 5000

• key-size 512: for AES-256 in XTS mode
• argon2id: resistant to GPU and side-channel attacks
• sha3-512: strong hash function for key derivation

Alternatives to AES-XTS

While aes-xts-plain64 is widely trusted and efficient (especially on CPUs with AES-NI), alternatives exist:

Cipher	Pros	Notes
serpent-xts-plain64	Conservative, strong security	Slower than AES
twofish-xts-plain64	Good balance of speed and trust	Suitable for older CPUs
camellia-xts-plain64	AES competitor, standardized	Not always available
chacha20 (custom use)	Stream cipher, fast in software	Not natively supported in LUKS

Note: There is no such cipher as aes-xts-plain128 in cryptsetup.

To use AES-128 instead of AES-256 in XTS mode:

--cipher aes-xts-plain64 --key-size 256

Post-Quantum Cryptography Considerations

LUKS uses symmetric encryption, which is not broken by quantum computers—only weakened. For example, Grover’s algorithm halves AES-256’s effective security to ~128 bits, which is still strong.

To maximize post-quantum resilience:

• Use AES-256 (key-size 512 in XTS)
• Use Argon2id with large memory/time cost
• Use strong passwords or keyfiles
• Avoid RSA/ECC-based key unlock mechanisms (e.g., smartcards, TPM with RSA)

Experimental ideas (not supported by LUKS natively):

• Encrypt LUKS keyfile using Kyber (PQC key exchange)
• Unlock LUKS from a secure enclave or co-processor using PQC

Conclusion

While cryptsetup with LUKS is already quite strong, a few advanced configuration options can make it significantly more secure—even against future quantum threats. For maximum protection:

• Choose aes-xts-plain64 with a 512-bit key
• Use argon2id with high memory and iteration settings
• Use sha3-512 as hash for better entropy
• Regularly audit and update your keyslots

For those especially concerned about long-term data confidentiality, begin experimenting with post-quantum cryptography outside the LUKS ecosystem—particularly for key management.