Was ist AES-256-GCM und warum zählt es bei Notiz-Apps?

AES-256-GCM ist der authentifizierte Verschlüsselungsmodus von Signal, 1Password, WireGuard und TLS. Was der Name bedeutet und warum GCM CBC schlägt.

Mathis Belouar-Pruvot

· Gründer von Filarr · · 9 Min. Lesezeit

Kurze Antwort. AES-256-GCM ist ein authentifizierter Verschlüsselungsmodus, der AES-256 (die symmetrische Chiffre, die Regierungen, Banken und Signal verwenden) mit GCM (Galois/Counter Mode, der Manipulationen erkennt) kombiniert. Diesen Modus nutzen TLS 1.3, WireGuard, Signal und 1Password. Eine Notiz-App, die mit „AES-256-Verschlüsselung“ wirbt, sollte GCM (oder einen anderen authentifizierten Modus) angeben – reines AES-256-CBC ohne Authentifizierung ist ein Warnsignal.

Wenn eine datenschutzorientierte App sagt „Ihre Daten sind mit AES-256-Verschlüsselung geschützt“, ist diese Aussage unvollständig. AES-256 ist eine Chiffre, kein vollständiges Verschlüsselungsverfahren. Der Betriebsmodus ist genauso wichtig wie die Chiffre selbst – und ein schlecht gewählter Modus kann AES-256 praktisch wertlos machen.

Dieser Artikel erklärt AES-256-GCM in verständlicher Sprache: was jeder Bestandteil tut, warum es ältere Modi wie CBC schlägt, welche bekannten Fallstricke es gibt und worauf Sie achten sollten, wenn eine Notiz-App oder ein Dateispeicher damit wirbt.

Was bedeutet AES-256-GCM, Stück für Stück?

Der Name hat drei Teile: AES, 256 und GCM. Jeder davon bedeutet etwas Bestimmtes.

AES (Advanced Encryption Standard) ist eine symmetrische Chiffre, die das US-amerikanische National Institute of Standards and Technology 2001 standardisiert hat (FIPS 197). „Symmetrisch“ bedeutet, dass derselbe Schlüssel ver- und entschlüsselt. AES ist die am gründlichsten analysierte Chiffre der Welt und in ihrer vollen Form bis heute ungebrochen.

256 ist die Schlüssellänge in Bit. AES ist für drei Schlüssellängen definiert: 128, 192 und 256 Bit. AES-256 ist die stärkste Variante, mit einem Schlüsselraum von 2²⁵⁶ – astronomisch größer als alles, was ein Brute-Force-Angriff praktisch erreichen kann, selbst mit gedachter Quantenhardware (der Grover-Algorithmus halbiert die effektive Schlüssellänge, sodass AES-256 eine Post-Quanten-Sicherheit von 2¹²⁸ behält, was weiterhin nicht zu knacken ist).

GCM (Galois/Counter Mode) ist ein Betriebsmodus. AES allein verschlüsselt nur einen einzelnen 128-Bit-Block. Um Daten beliebiger Länge zu verschlüsseln, braucht man einen Modus, der Blöcke miteinander verkettet. GCM ist ein solcher Modus, und vor allem bietet er authentifizierte Verschlüsselung mit zugehörigen Daten (AEAD) – er verschlüsselt Ihre Daten nicht nur, sondern erzeugt auch ein Tag, das jede Manipulation erkennt.

Zusammengesetzt heißt AES-256-GCM also: „mit AES verschlüsseln, Schlüssellänge 256 Bit, in einem Modus, der Manipulationen erkennt“.

Warum ist GCM wichtig? Ist AES nicht schon sicher?

Als Blockchiffre ist AES sicher. Aber Blockchiffren allein sind nutzlos – Sie brauchen einen Betriebsmodus, und die Wahl des Modus bestimmt die Sicherheitseigenschaften des gesamten Systems.

Der klassische Fehler ist AES im CBC-Modus ohne Authentifizierung. CBC verschlüsselt Ihre Daten korrekt, sagt Ihnen aber nicht, ob der Geheimtext manipuliert wurde. Ein Angreifer, der Bits im verschlüsselten Blob umkippen kann, kann Ihren Klartext auf vorhersehbare Weise verfälschen – eine Angriffsklasse, die als „Padding-Oracle“-Angriffe bekannt ist (siehe die Angriffe BEAST und Lucky 13 auf TLS mit CBC). Die Entschlüsselung gelingt, aber Sie erhalten einen manipulierten Klartext zurück.

GCM löst das, indem es zusätzlich zum Geheimtext ein Galois-MAC-Tag (GMAC) berechnet. Passt das Tag beim Entschlüsseln nicht, schlägt die Entschlüsselung fehl – Sie bekommen nie manipulierten Klartext zu sehen. Das ist authentifizierte Verschlüsselung, und 2026 ist sie die einzige akzeptable Wahl für neue Systeme.

ModusVerschlüsselt?Erkennt Manipulation?Status
AES-ECBJa (schlecht)NeinGebrochen – nie verwenden
AES-CBC (ohne MAC)JaNeinVermeiden
AES-CBC + HMACJaJa (bei richtiger Kombination)In Ordnung, aber fehleranfällig
AES-GCMJaJa (eingebaut)Empfohlen
AES-OCBJaJa (eingebaut)Historisch durch Patente belastet
ChaCha20-Poly1305Ja (andere Chiffre)Ja (eingebaut)Gleichwertige Alternative

Wie funktioniert GCM eigentlich?

GCM kombiniert zwei Operationen:

  1. Verschlüsselung im Counter-Modus (CTR). GCM nimmt eine 96-Bit-Nonce („number used once“, eine nur einmal verwendete Zahl), hängt einen 32-Bit-Zähler an, verschlüsselt diesen Block mit AES und verknüpft das Ergebnis per XOR mit jedem Klartextblock. So wird AES zu einer Stromchiffre. Jeder Block verwendet einen anderen Zählerwert, sodass identische Klartexte unterschiedliche Geheimtexte ergeben.

  2. MAC über einem Galois-Körper. Parallel zur Verschlüsselung berechnet GCM einen Polynom-Hash in GF(2¹²⁸) über den Geheimtext und alle zugehörigen Daten (Header, Metadaten). Das Ergebnis ist ein 128-Bit-Authentifizierungstag, das an den Geheimtext angehängt wird.

Zum Entschlüsseln wiederholt GCM die GMAC-Berechnung, vergleicht das Ergebnis mit dem empfangenen Tag und entschlüsselt nur, wenn beide übereinstimmen. Ein einziges umgekipptes Bit im Geheimtext = Tags stimmen nicht überein = die Entschlüsselung verweigert die Herausgabe des Klartexts.

Die Leistung ist hervorragend: GCM lässt sich parallelisieren (Counter-Modus), und moderne Prozessoren implementieren sowohl AES als auch die Multiplikation in GF(2¹²⁸) in Hardware (die Befehle Intel AES-NI und PCLMULQDQ). Auf einem Laptop von 2026 läuft AES-256-GCM mit 5–10 GB/s.

Was ist die tödliche Falle von AES-GCM?

GCM hat eine kritische Regel, und ein Verstoß hat echte Folgen: Verwenden Sie eine Nonce nie zweimal mit demselben Schlüssel. Die 96-Bit-Nonce muss für jede Verschlüsselung mit einem bestimmten Schlüssel einmalig sein.

Wird eine Nonce wiederverwendet, brechen bei GCM Vertraulichkeit und Authentizität gleichzeitig zusammen. Ein Angreifer, der zwei Geheimtexte sieht, die mit demselben Paar (Schlüssel, Nonce) verschlüsselt wurden, kann:

  • sie per XOR verknüpfen und so das XOR der Klartexte erhalten (ist ein Stück des einen bekannt, fällt der andere)
  • den GMAC-Authentifizierungsunterschlüssel rekonstruieren und dann beliebige Geheimtexte fälschen, die zu allem entschlüsseln, was er möchte

Das nennt man den Forbidden Attack, und deshalb müssen GCM-Implementierungen sorgfältig sein. NIST SP 800-38D (der GCM-Standard) begrenzt die Zahl der Verschlüsselungen pro Schlüssel bei zufälligen Nonces auf 2³², bevor das Risiko einer Nonce-Wiederverwendung inakzeptabel wird.

Nonce-Wiederverwendung hatte in der Praxis bereits echte Folgen – am bekanntesten in einigen frühen Bluetooth-Implementierungen, in WPA2 (der KRACK-Angriff) und in frühen GCM-Implementierungen für TLS. Eine korrekte Implementierung verwendet entweder einen deterministischen Zähler oder zufällige Nonces pro Nachricht mit dokumentierten Grenzen für den Schlüsselwechsel.

Wenn Sie die Verschlüsselung einer Notiz-App bewerten, lautet die richtige Frage also nicht „Verwenden Sie AES-256-GCM?“, sondern „Wie erzeugen Sie Nonces, und wie oft wechseln Sie die Schlüssel?“

Warum setzen Notiz-Apps auf AES-256-GCM?

Für Notizen und Dateien ist AES-256-GCM die richtige Wahl, weil es:

  • standardisiert ist. NIST SP 800-38D, im Einsatz bei TLS 1.3, WireGuard, Signal und IPsec.
  • schnell ist. Hardwarebeschleunigt auf jedem Prozessor der letzten zehn Jahre.
  • Manipulationen erkennt. Verändert ein Server (oder ein Angreifer) Ihre verschlüsselte Notiz, schlägt die Entschlüsselung sofort fehl. Sie lesen nie verfälschten Klartext.
  • überall verfügbar ist. Es gibt Implementierungen im crypto-Modul von Node.js, in SubtleCrypto im Browser, in libsodium, OpenSSL, der Standardbibliothek von Go und im Rust-Crate aes-gcm.

Bei einer Notiz-App sieht das typische Muster so aus:

  1. Das Passwort des Nutzers durchläuft eine langsame Schlüsselableitungsfunktion (PBKDF2 oder Argon2id), die daraus einen Hauptschlüssel erzeugt – siehe KEK und FEK erklärt.
  2. Jede Notiz (oder jede Datei) erhält einen eigenen zufälligen 256-Bit-Datenschlüssel.
  3. Der Datenschlüssel verschlüsselt die Notiz mit AES-256-GCM, mit einer frischen zufälligen oder zählerbasierten Nonce.
  4. Der Datenschlüssel selbst wird mit dem Hauptschlüssel verschlüsselt („verpackt“), ebenfalls mit AES-256-GCM.

Bei dieser Architektur mit einem Datenschlüssel für jede Datei legt ein einzelner kompromittierter Datenschlüssel nur eine Datei offen, nicht den ganzen Tresor. Filarr geht einen einfacheren Weg: Dateien und Notizen werden unter einem einzigen Kontoschlüssel (dem FEK) verschlüsselt, mit einem neuen Zufallswert (IV) für jede Datei; nur große, auf dem Desktop importierte Dateien und synchronisierte Blöcke leiten zusätzlich einen gesonderten Schlüssel aus dem FEK ab. Der FEK öffnet also das ganze Konto, und deshalb ist ein starkes Passwort so wichtig – die genauen Parameter finden Sie in der Sicherheitsarchitektur von Filarr.

Worauf sollten Sie achten, wenn eine Notiz-App mit „AES-256-Verschlüsselung“ wirbt?

Wenn eine datenschutzorientierte App mit AES-256-Verschlüsselung wirbt, stellen Sie folgende Fragen:

  1. Welcher Modus? GCM oder ein anderer authentifizierter Modus ist Pflicht. Reines CBC, ECB oder „AES-256“ ohne Angabe eines Modus ist ein Warnsignal.
  2. Wie wird der Schlüssel abgeleitet? Direkt aus dem Passwort des Nutzers? Das ist falsch – Passwörter haben zu wenig Entropie. Es braucht eine Schlüsselableitungsfunktion (PBKDF2, Argon2id, scrypt) mit dokumentierter Iterationszahl.
  3. Gibt es Schlüssel für jede einzelne Datei oder einen globalen Schlüssel? Schlüssel für jede einzelne Datei (oder Notiz) begrenzen den Schaden – die Kompromittierung eines einzelnen Schlüssels legt nicht alles offen.
  4. Wie werden Nonces erzeugt? Deterministischer Zähler? Zufällig, mit wie vielen Bits? „Wir verwenden AES-GCM“ ohne Disziplin bei den Nonces ist fragil.
  5. Wo ist die Verschlüsselung dokumentiert? Eine seriöse App veröffentlicht ihr Bedrohungsmodell und ihr Verschlüsselungsdesign. Wenn Sie nichts davon finden, gehen Sie von Kryptografie auf Marketingniveau aus.
  6. Lässt sich der Code prüfen? Quelloffene Implementierungen erlauben Sicherheitsforschern, die Aussagen zu überprüfen. Geschlossenes AES-256 ist ein Versprechen, kein Beweis.

Wie verwendet Filarr AES-256-GCM?

Filarr verschlüsselt jede Datei und jede Notiz mit AES-256-GCM unter dem Kontoschlüssel (FEK), mit einem neuen Zufallswert pro Datei. Der vollständige Ablauf:

  • Ihr Passwort wird mit PBKDF2-SHA-512 und 600.000 Iterationen gestreckt (weit über den 210.000, die die OWASP für PBKDF2-SHA512 empfiehlt), um einen Key Encryption Key (KEK) zu erzeugen
  • Ihr Konto oder Ihr lokales Profil hat einen einzigen zufälligen 256-Bit-File-Encryption-Key (FEK)
  • Jede Datei und jede Notiz wird mit AES-256-GCM unter dem FEK verschlüsselt, mit einem neuen zufälligen IV (der Nonce) für jede; nur große, auf dem Desktop importierte Dateien und synchronisierte Blöcke leiten zusätzlich einen gesonderten Schlüssel aus dem FEK ab
  • Der FEK wird mit dem KEK verschlüsselt, ebenfalls mit AES-256-GCM, und eine zweite Kopie wird unter Ihrer Wiederherstellungsphrase verpackt

Der KEK wird auf Ihrem Gerät berechnet, und der FEK gelangt nur verpackt auf unsere Server. Würde unser Speicher für die Cloud-Synchronisierung gestohlen, sähe ein Angreifer nur einen Strom verschlüsselter Blobs, die er nicht entschlüsseln kann – unsere Server halten Ihren Schlüssel nur in verpackter Form. Die bekannte Grenze schließt sich gerade: Seit dem 16. Oktober 2026 sendet die Anmeldung nicht mehr Ihr Passwort, sondern einen auf Ihrem Gerät abgeleiteten Schlüssel. Während einer Übergangszeit von etwa zwei Monaten geht das Passwort in zwei Fällen noch an unsere Server: bei einer älteren App-Version (Desktop vor 3.8.1, Mobil vor 1.7) und bei der ersten Anmeldung eines vor dem 16. Oktober 2026 erstellten Kontos; in diesen Fällen könnte ein kompromittierter Server es abfangen. Die vollständige Architektur und das Bedrohungsmodell beschreibt das Sicherheitsmodell von Filarr.

Weiterführende Lektüre

Ähnliche Artikel