Skip to main content

GPG - Sicheren Schlüssel erstellen und Ordner verschlüsseln

2) GPG-Konfiguration hart setzen – was, warum, wann?

In diesem Schritt definieren wir, welche Algorithmen GnuPG bevorzugt (ohne dir exotische Kommandos zuzumuten), welche Metadaten wir weglassen, und wie wir Empfängerinformationen verschleiern können. Das Ziel ist, dass GnuPG bei jeder Verschlüsselung automatisch die robustesten Verfahren auswählt – und zwar so, dass du im Alltag nichts vergisst.

2.0) Grundidee: „Präferenzen“ vs. „erzwingen“
  • Präferenzen (gpg.conf, personal-*) sagen: „Wenn möglich, nimm diese starken Verfahren zuerst.“ Das ist kompatibel und alltagstauglich.
  • Erzwingen (z. B. --cipher-algo AES256) überstimmt alles – nützlich für eigene Backups, aber kann die Zusammenarbeit mit sehr alten Gegenstellen bremsen.
Nun musst du folgenden Schritt machen: Öffne oder erstelle ~/.gnupg/gpg.conf und trage Folgendes ein.
# Starke, moderne Defaults bevorzugen (Vertraulichkeit + Integrität)
personal-cipher-preferences AES256 AES192 AES
personal-digest-preferences SHA512 SHA384 SHA256
cert-digest-algo SHA512

# Kleine Metadaten-Fußabdrücke in ASCII-Armor:
no-emit-version
no-comments

# (Optional) Empfänger-IDs im Ciphertext verbergen (Traffic-Analyse erschweren)
throw-keyids
Warum?
  • AES-256 bietet sehr starke Vertraulichkeit; SHA-512 hält Signaturen & S2K-Ableitungen robust.
  • no-emit-version/no-comments entfernen triviale „Banner“ aus ASCII-Armor (rein kosmetisch, aber gut gegen überflüssige Fingerprints).
  • throw-keyids bewirkt, dass im Ciphertext nicht steht, für welchen Key er gedacht ist; der Empfänger probiert dann seine Keys durch – etwas langsamer, dafür weniger verräterisch.
2.1) Authenticated Encryption (AEAD/OCB) verständlich

GnuPG unterstützt moderne AEAD-Modi (insb. OCB), bei denen Daten gleichzeitig verschlüsselt und authentifiziert werden; Manipulationen fallen dadurch strikt auf. Für eigene Backups oder Workflows, die du ausschließlich mit aktueller GnuPG-Version verarbeitest, kannst du AEAD gezielt bevorzugen.

Optional, wenn du nur mit modernen GnuPGs arbeitest: AEAD/OCB erzwingen.
# Beim Verschlüsseln:
gpg --encrypt -r "$EMPFAENGER" --cipher-algo AES256 --force-ocb -o out.gpg -- in.dat
# (In Skripten/Backups sehr sinnvoll. Für Austausch mit Alt-Clients ggf. weglassen.)
Wann nicht? Für Empfänger mit anderen OpenPGP-Implementierungen (ältere Apps, Mobil-Clients) kann OCB/AHEAD noch haken. Für maximalen Datenaustausch lässt du --force-ocb weg; für eigene Langzeit-Backups ist es top.
2.2) Empfänger verschleiern – wann es sinnvoll ist

In manchen Situationen möchtest du vermeiden, dass im Ciphertext steht, für wen er gedacht ist (z. B. bei Upload in geteilte Zonen). Das ist kein Allheilmittel gegen Traffic-Analyse, aber eine nützliche Erschwernis.

# Einmalig in gpg.conf: throw-keyids (s. oben)  ODER pro Aufruf:
gpg --encrypt --hidden-recipient "$EMPFAENGER" -o out.gpg -- in.dat
# Nachteil: Entschlüsseln kann minimal länger dauern (alle eigenen Keys werden probiert).
2.3) Agent-Verhalten härten (Passphrase-Caching)

Der gpg-agent puffert Passphrasen standardmäßig kurzzeitig, um dich nicht bei jeder Aktion zu nerven. Wenn „maximal sicher“ wichtiger als Bequemlichkeit ist, schalte das Caching ab.

Nun musst du folgenden Schritt machen: Öffne oder erstelle ~/.gnupg/gpg-agent.conf und setze:
no-allow-external-cache
default-cache-ttl 0
max-cache-ttl 0
pinentry-timeout 0

# Änderungen laden:
gpgconf --reload gpg-agent
Warum? Ohne Cache brauchst du die Passphrase häufiger, aber ein fremder Benutzer auf demselben System oder Malware kann sie nicht „abgreifen“, solange sie nicht im Speicher gehalten wird.
2.4) „S2K“ (String-to-Key) gezielt hochdrehen – wozu das gut ist

S2K ist der Prozess, der aus deiner Passphrase einen Schlüssel ableitet, um deine privaten Schlüsseldateien zu schützen (und bei symmetrischer Verschlüsselung die Daten). Moderne GnuPG-Versionen kalibrieren die Iterationszahl automatisch (~100 ms). Wenn du auf einer starken Maschine bewusst mehr Rechenzeit investieren willst, kannst du den Zielwert erhöhen.

Optional (fortgeschritten, sinnvoll für starke Hosts):
# In ~/.gnupg/gpg-agent.conf z. B. 500 ms Zielzeit:
s2k-calibration 500

# Alternativ: feste Iterationen (statt Zeitbasierung):
# s2k-count 33554432   # Beispiel (~33 Mio). Teste die Performance!

# Danach neu laden:
gpgconf --reload gpg-agent

# Kontrollblick:
gpg-connect-agent 'GETINFO s2k_time' /bye
gpg-connect-agent 'GETINFO s2k_count' /bye
Wichtig: Zu hohe Werte können auf schwächeren Geräten (z. B. Laptop auf Akku) nerven. Richte dich nach deinem Nutzungsszenario und teste.
2.5) Wie überprüfe ich, was tatsächlich verwendet wurde?
  • gpg --version zeigt, welche Algorithmen deine GnuPG-Installation unterstützt (Ciphers, AEAD-Modi, Hashes).
  • gpg --list-options show-pref-verbose --list-keys zeigt Key-Präferenzen (was andere nutzen, wenn sie dir schreiben).
  • gpg --list-packets datei.gpg zeigt Paket-Details zu einer konkret erzeugten Datei (nützlich fürs Audit).
2.6) Wann reicht „Präferenzen setzen“ – und wann „erzwingen“?
  • Team-Kommunikation, E-Mail, Austausch mit Dritten: Präferenzen in gpg.conf + saubere Schlüssel-Präferenzen genügen (kompatibel, robust).
  • Eigene Backups, Archivierung, Offline-Tresore: Du darfst erzwingen (--cipher-algo AES256, optional --force-ocb), weil du die Entschlüsselungsumgebung kontrollierst.
2.7) Bonus: Schlüssel-Präferenzen auf dem Key selbst aktualisieren

Deine Schlüsselkarte (der Public-Key) enthält Präferenzen, die andere sehen, wenn sie dir verschlüsseln. Aktualisiere sie einmalig und verteile den aktualisierten Public-Key, damit Sender automatisch starke Verfahren wählen.

gpg --edit-key <Fingerprint-oder-UID>
gpg> showpref
gpg> setpref SHA512 SHA384 SHA256 AES256 AES192 AES ZLIB BZIP2 ZIP Uncompressed
gpg> save
Warum? So teilst du der Welt mit: „Bitte nimm starke Hashes/Cipher zuerst“. GnuPG verhandelt beim Verschlüsseln den Schnitt aus Sender- und Empfänger-Präferenzen – mit dieser Reihenfolge landest du fast immer bei den starken Varianten.
Back to top