Verschlüsselung unter Debian 13 und CachyOS: LUKS, Dateien, Archive

Vier Ebenen, vier Werkzeuge

Die häufigste Enttäuschung beim Thema Verschlüsselung entsteht durch die falsche Ebene: Ein verschlüsseltes Backup-Archiv schützt nicht den laufenden Server, ein LUKS-Container schützt keine E-Mail auf dem Weg, und eine TLS-Verbindung schützt keine Festplatte, die verkauft wird.

Und genauso wichtig: Was Verschlüsselung nicht leistet.

Was Verschlüsselung wirklich kostet

Bevor man über Verfahren diskutiert, hilft eine Messung auf der eigenen Maschine. cryptsetup bringt dazu einen Benchmark mit, der die CPU-Leistung der Kernel-Krypto-Schnittstelle misst – ohne einen Datenträger zu berühren. Auf dem Testsystem (Ryzen 9 9950X3D, cryptsetup 2.8.7 mit KERNEL_CAPI-Unterstützung) ergibt das:

cryptsetup benchmark

PBKDF2-sha1      6061132 Iterationen pro Sekunde für 256-Bit-Schlüssel
PBKDF2-sha256    9664294 Iterationen pro Sekunde für 256-Bit-Schlüssel
PBKDF2-sha512    4619277 Iterationen pro Sekunde für 256-Bit-Schlüssel
argon2i      19 Iterationen, 1048576 Speicher, 4 parallele Threads (Zieldauer 2000 ms)
argon2id     19 Iterationen, 1048576 Speicher, 4 parallele Threads (Zieldauer 2000 ms)
#   Algorithmus | Schlüssel | Verschlüsselung | Entschlüsselung
        aes-cbc        128b      1783,0 MiB/s      9195,2 MiB/s
    serpent-cbc        128b       189,0 MiB/s      1124,7 MiB/s
    twofish-cbc        128b       382,5 MiB/s       926,6 MiB/s
        aes-cbc        256b      1333,3 MiB/s      7211,9 MiB/s
        aes-xts        256b     15764,0 MiB/s     15822,7 MiB/s
    serpent-xts        256b       900,6 MiB/s      1022,6 MiB/s
    twofish-xts        256b       848,6 MiB/s       872,6 MiB/s
        aes-xts        512b     14192,7 MiB/s     14242,0 MiB/s

Drei Zahlen daraus sind die ganze Diskussion:

Warum AES so schnell ist, verrät der Kernel direkt – hier die tatsächlich benutzte Implementierung:

grep -A8 -m1 'name         : xts(aes)' /proc/crypto

name         : xts(aes)
driver       : xts-aes-vaes-avx512
module       : aesni_intel
priority     : 800
selftest     : passed
type         : skcipher

vaes-avx512 heißt: Der Prozessor rechnet AES in Vektorregistern, mehrere Blöcke parallel. Auf älteren CPUs steht dort xts-aes-aesni oder – ohne AES-NI – eine Softwarevariante mit einem Bruchteil des Durchsatzes. Für Transportverschlüsselung (TLS, VPN) sind die Zahlen ähnlich eindeutig:

openssl speed -seconds 1 -evp aes-256-gcm      # Auszug (1000 Byte/s)
AES-256-GCM     196873.39k  …  20114489.34k 23134406.59k
                16 B → 0,2 GB/s   |   16 KB → 23,1 GB/s

openssl speed -seconds 1 -evp chacha20-poly1305
ChaCha20-Poly1305 374769.05k …  6563414.02k
                16 B → 0,37 GB/s  |   16 KB → 6,6 GB/s

openssl speed -seconds 1 ed25519
                 sign    verify    sign/s verify/s
  EdDSA (Ed25519) 0.0000s 0.0001s  61909.1  18056.0

LUKS2: Datenträger verschlüsseln

Der Einstieg passiert bei der Installation: Debian 13 bietet im Installer „verschlüsseltes LVM“ (LUKS2 seit Debian 12 als Standard), CachyOS bietet im Calamares-Installer die Option „Verschlüsselt“ mit LUKS2. Wer beides nicht angeklickt hat, kann später nachrüsten (siehe Nachträglich verschlüsseln).

Für eigene Datenträger genügen drei Befehle. Wichtig ist --type luks2 (Argon2id statt PBKDF2+Anti-Forensik-Stripes) und eine Passphrase, die nicht im Verlauf landet:

# Debian 13
sudo apt install cryptsetup cryptsetup-initramfs

# CachyOS / Arch
sudo pacman -S cryptsetup

# Datenträger verschlüsseln (VORSICHT: löscht alles auf /dev/sdX)
sudo cryptsetup luksFormat --type luks2 /dev/sdX1

# Öffnen (verlangt die Passphrase) und Dateisystem anlegen
sudo cryptsetup open /dev/sdX1 daten
sudo mkfs.ext4 /dev/mapper/daten
sudo mount /dev/mapper/daten /mnt/daten

Was LUKS2 dabei anlegt, zeigt der Header – hier eine echte Ausgabe eines Testcontainers (Header auf einer Datei erzeugt, ohne root):

cryptsetup luksDump t.img

LUKS header information
Version:       	2
Epoch:         	3
Metadata area: 	16384 [bytes]
Keyslots area: 	16744448 [bytes]
UUID:          	29e4b34e-2fe4-4370-aaf0-24924ab494d5

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

Keyslots:
  0: luks2
	Key:        512 bits
	Cipher:     aes-xts-plain64
	Cipher key: 512 bits
	PBKDF:      argon2id
	Time cost:  19
	Memory:     1048576
	Threads:    4
	Salt:       62 b1 c3 f0 e2 75 b9 1d … 
	AF stripes: 4000
	AF hash:    sha256

LUKS im Betrieb: Keyslots, crypttab, Keyfiles

Jeder „Schlüssel“ steckt in einem eigenen Keyslot. Das ist der Mechanismus, mit dem man eine Passphrase ändert oder zusätzlich ein Keyfile (z. B. für das NAS) hinterlegt, ohne alles neu zu verschlüsseln. Die folgende Ausgabe stammt aus dem Testcontainer: erst ein Keyfile, dann ein zweiter Keyslot, dann die Umstellung von Slot 0 auf PBKDF2 für GRUB-Kompatibilität:

# zweiten Keyslot anlegen (Keyfile statt Passphrase)
cryptsetup luksAddKey --key-file key1 t.img key2
cryptsetup luksDump t.img | grep -E '^  [0-9]+: luks2|PBKDF|Memory'
  0: luks2
	PBKDF:      argon2id
	Memory:     1048576
  1: luks2
	PBKDF:      argon2id
	Memory:     1048576

# Keyslot 0 auf PBKDF2 umstellen (nötig, wenn GRUB die Passphrase abfragen soll)
cryptsetup luksConvertKey --key-file key1 --pbkdf pbkdf2 --pbkdf-force-iterations 1000000 t.img
cryptsetup luksDump t.img | grep -A6 '^  0: luks2'
  0: luks2
	Key:        512 bits
	Cipher:     aes-xts-plain64
	Cipher key: 512 bits
	PBKDF:      pbkdf2
	Hash:       sha256

# /etc/crypttab – Feld 2 ist die Keyfile mit den Rechten 0400, root:root
# <Name>            <Gerät>              <Keyfile>        <Optionen>
daten               UUID=…               /etc/luks/daten.key   luks,discard,nofail

# Passphrase zusätzlich verlangen (statt nur Keyfile): Schlüsselwort "none" im Keyfile-Feld
systemd-cryptsetup-generator --help     # erzeugt die Units automatisch aus crypttab
systemctl status systemd-cryptsetup@daten.service

Der LUKS-Header: dein wertvollstes Datum

Der LUKS-Header enthält alles, was zum Öffnen nötig ist: die Keyslots, die mit deiner Passphrase geschützten Hauptschlüssel und die Metadaten. Ist der Header weg, sind die Daten weg – auch mit korrekter Passphrase. Deshalb gehört er in jedes Backup:

# Header sichern (Datei wie ein Passwort behandeln!)
sudo cryptsetup luksHeaderBackup /dev/sdX --header-backup-file /root/luks-header-sdX.img
ls -la /root/luks-header-sdX.img
-r-------- 1 root root 16777216 … luks-header-sdX.img        # 16 MiB bei LUKS2

# Wiederherstellen (z. B. nach versehentlichem luksFormat)
sudo cryptsetup luksHeaderRestore /dev/sdX --header-backup-file /root/luks-header-sdX.img

Ohne Passphrase aufschließen: TPM2 und FIDO2

Auf Servern und Laptops mit TPM2 lässt sich die Passphrase durch Hardware binden – bequem (kein Tippen) und gefährlich (wer den Rechner hat, hat die Daten). systemd kann das direkt:

sudo systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=0+7 /dev/sdX
sudo systemd-cryptenroll --fido2-device=auto /dev/sdX          # Sicherheitsschlüssel statt TPM
sudo systemd-cryptenroll --recovery-key /dev/sdX               # Notfallschlüssel erzeugen
systemd-cryptenroll --list-devices 2>/dev/null || sudo systemd-cryptenroll /dev/sdX

Nachträglich verschlüsseln

Ein bestehendes System lässt sich verschlüsseln, ohne Daten zu verlieren – aber nur mit Backups und Zeit. LUKS2 kann einen bestehenden Datenträger im laufenden Betrieb verschlüsseln („reencrypt“ mit Datenverschiebung), was bei einer halbvollen Platte Stunden dauern kann und einen Neustart übersteht nur begrenzt:

# Zustand ansehen: was passiert gerade?
sudo cryptsetup luksDump /dev/sdX | grep -A3 'Data segments'

# Neuen LUKS2-Header anlegen und bestehende Daten verschlüsseln (LUKS2-Reencryption)
sudo cryptsetup reencrypt --encrypt --type luks2 --reduce-device-size 32M /dev/sdX

# Fortschritt beobachten, Reencryption-Status abfragen
sudo cryptsetup luksDump /dev/sdX | grep -E 'online|reencrypt'
sudo cryptsetup reencrypt --resume-only /dev/sdX

Dateien und Ordner: gocryptfs, crypt, fscrypt

Oft braucht es keine ganze Platte: Ein einzelnes Verzeichnis soll verschlüsselt in eine Cloud oder auf einen USB-Stick – dort sind Dateinamen und Struktur schon Teil des Problems. Verzeichnisverschlüsselung arbeitet mit einem Klartext-Mount und einem Chiffrat-Verzeichnis:

# Debian 13
sudo apt install gocryptfs
# CachyOS / Arch
sudo pacman -S gocryptfs

# Chiffrat-Ordner anlegen und initialisieren
mkdir -p ~/Cloud/chiffrat ~/klartext
gocryptfs -init ~/Cloud/chiffrat          # Passphrase + Masterkey zweimal bestätigen

# Klartext mounten (bleibt bis unmount im Speicher verfügbar)
gocryptfs ~/Cloud/chiffrat ~/klartext

# Aufräumen: unmounten beendet den Klartextzugriff
fusermount3 -u ~/klartext

Für Cloud-Sync mit rclone ist der Aufbau derselbe, nur eine Ebene höher:

rclone config create cloud crypt remote=mein-remote filename_encryption=standard \
       directory_name_encryption=true
rclone ls cloud:                       # zeigt entschlüsselte Namen
rclone ls mein-remote:                 # zeigt nur Chiffrat (unlesbar)

Archive und Backups: 7z, age, GPG, restic

Auf dieser Ebene verlassen Daten das Haus – hier zählt, dass die Verschlüsselung authentifiziert ist (Manipulation fällt auf) und dass die Passphrase nicht im Skript steht. Die vier Kandidaten im Vergleich:

# 7z: AES-256 mit verschlüsselten Dateinamen (-mhe=on)
7z a -p'SECRET' -mhe=on backup.7z ordner/

# Was steckt drin? (Listing braucht bei -mhe das Passwort)
7z l -slt -pSECRET backup.7z | grep -E '^(Path|Method|Encrypted)'
Path = backup.7z
Method = LZMA2:12 7zAES            # Header
Path = klar.txt
Method = LZMA2:12 7zAES:19         # Datei
Encrypted = +

# Test mit falschem Passwort: klare Fehlermeldung statt Datenmüll
7z t -pFALSCH backup.7z
ERROR: backup.7z
Cannot open encrypted archive. Wrong password?

GPG ist der alte Standard und zeigt im Paketformat sehr schön, wie eine Passphrase-Verwaltung aussieht – hier eine echte symmetrische Verschlüsselung mit GnuPG 2.4.9:

gpg --symmetric --cipher-algo AES256 --pinentry-mode loopback --passphrase 'testpass' klar.txt
gpg --list-packets klar.txt.gpg

:symkey enc packet: version 4, cipher 9, aead 0, s2k 3, hash 10
	salt FED63E48EFCAF08D, count 65536 (96)
:encrypted data packet:

Und das Gegenbeispiel für die „mal schnell“-Fraktion – openssl enc funktioniert, ist aber nicht authentifiziert:

openssl enc -aes-256-cbc -pbkdf2 -iter 200000 -salt -in klar.txt -out ssl.enc -pass pass:testpass
ls -la klar.txt ssl.enc
-rw-r--r-- 1 ba0 ba0 27 … klar.txt
-rw-r--r-- 1 ba0 ba0 48 … ssl.enc

# Rückweg
openssl enc -d -aes-256-cbc -pbkdf2 -iter 200000 -in ssl.enc -pass pass:testpass
Das ist ein Testgeheimnis.

Schlüssel und Zugänge

Beim SSH-Schlüssel steckt die Verschlüsselung im Dateiformat – und sehr viele kennen nur den Teil bis zum `-t ed25519`. Das Testsystem zeigt, was wirklich im privaten Schlüssel steht (OpenSSH 10.5p1):

ssh-keygen -t ed25519 -a 100 -C 'test@huuu.biz' -N 'geheim' -f k_ed
ssh-keygen -l -f k_ed
256 SHA256:RozPBNrD0d3iYxoHvJYlouW6XQKGwB7BfvccpJhyi70 test@huuu.biz (ED25519)
stat -c 'Rechte: %a  Größe: %s Bytes' k_ed
Rechte: 600  Größe: 444 Bytes

# Kopfdaten des openssh-key-v1-Formats ausgelesen:
Format     : openssh-key-v1
Cipher     : aes256-ctr
KDF        : bcrypt
bcrypt     : 100 Runden (ssh-keygen -a 100)
Salt       : 2c4075f9a39b0186d5c507ca04fb08ee

# Neuer, moderner Schlüssel mit erhöhten KDF-Runden
ssh-keygen -t ed25519 -a 100 -C 'ich@example.org'
# Fingerprint zur Kontrolle auf dem Server (gegen MITM-Abwehr)
ssh-keyscan -t ed25519 server.example | ssh-keygen -lf -
# Agent nutzen, damit die Passphrase im Speicher bleibt statt im Verlauf
eval "$(ssh-agent -s)" && ssh-add ~/.ssh/id_ed25519

Praxis: Swap, Container, Stick, Laptop

# systemd-creds: Secrets an das System binden (kein Klartext in Dateien)
sudo systemd-creds encrypt --name=db-pass pass.txt /etc/credstore.encrypted/db-pass
# Docker: Secrets statt Umgebungsvariablen
docker secret create db_pass pass.txt 2>/dev/null || echo "Swarm-Modus: docker secret braucht einen Swarm"

Fehlerbild → Prüfbefehl

Regeln für den Alltag

Was hier nicht getestet wurde

Geprüft heißt: in dieser Umgebung selbst ausgeführt. Der Rest stammt aus Dokumentation und Paketquellen.

Fazit

Verschlüsselung ist auf Debian und CachyOS kein Projekt, sondern eine Reihe kleiner Entscheidungen: LUKS2 für Datenträger (mit Header-Backup!), Verzeichnisverschlüsselung für das, was in die Cloud geht, authentifizierte Archive (age, GPG, 7z) für alles, was das Haus verlässt, und Schlüssel, die niemals neben ihren Daten liegen. Die Krypto selbst ist dabei das kleinste Problem: AES-XTS verschlüsselt auf dem Testsystem mit 15,7 GB/s – schneller als jede NVMe. Teuer ist nur die Passphrase, und genau das ist der Punkt, an dem Sicherheit entsteht.