Schützen Sie die Daten Ihres Unternehmens mit diesen Verschlüsselungsalgorithmen

Die Wahl des Verschlüsselungsalgorithmus bestimmt die Stärke Ihres Datenschutzes: Eine falsche Wahl kann Daten anfällig für Brute-Force-Angriffe, bekannte kryptanalytische Schwachstellen oder zukünftige Bedrohungen durch Quantencomputer machen. Datenverschlüsselung wandelt Klartext in Geheimtext um, der nur von autorisierten Parteien mit dem korrekten Schlüssel gelesen werden kann. Empfohlen wird: Verwenden Sie AES-256-GCM für ruhende Daten, TLS 1.3 mit ECDHE für Daten während der Übertragung, ECC P-256 oder RSA-3072 für asymmetrische Operationen und vermeiden Sie DES und 3DES bei allen neuen Implementierungen. Das Schlüsselmanagement, nicht der Algorithmus selbst, ist die häufigste Fehlerquelle bei Verschlüsselungsimplementierungen.

Kurzantwort: Welchen Verschlüsselungsalgorithmus sollte Ihre Organisation verwenden?

Der Algorithmus hängt vom Anwendungsfall des Datenschutzes ab. Für ruhende Daten empfiehlt sich AES-256-GCM: schnell, vom NIST empfohlen und bietet authentifizierte Verschlüsselung mit Manipulationserkennung zusätzlich zur Verschlüsselung. Für Datenübertragung ist TLS 1.3 mit den Verschlüsselungssuiten AES-256-GCM oder ChaCha20-Poly1305 und ECDHE-Schlüsselaustausch für Forward Secrecy zu verwenden. Für digitale Signaturen und Zertifikate empfiehlt sich ECDSA P-256 (bevorzugt für neue Implementierungen aufgrund der kleineren Schlüssellänge und der schnelleren Operationen) oder RSA-3072 (Minimum; RSA-2048 ist das absolute Minimum und soll gemäß NIST IR 8547 nach 2030 abgeschafft werden). Vermeiden Sie DES (56-Bit-Schlüssel, unsicher), 3DES (2019 vom NIST für neue Anwendungen offiziell als veraltet eingestuft, Sweet32-Schwachstelle), RC4 und MD5. Für die Post-Quanten-Technologie sollten Sie die Migration asymmetrischer Algorithmen zu ML-KEM (FIPS 203) und ML-DSA (FIPS 204) planen.

Vergleich von Verschlüsselungsalgorithmen

Die folgende Tabelle vergleicht die gängigsten Verschlüsselungsalgorithmen hinsichtlich der für Sicherheitsentscheidungen relevanten Kriterien. Dieser Blog konzentriert sich insbesondere auf die operative Auswahlhilfe: Welcher Algorithmus eignet sich für welchen Anwendungsfall und warum? Zudem wird der jeweilige NIST-Konformitätsstatus explizit angegeben.

Algorithmus	Typ	Schlüsselgröße	Sicherheitsstärke	Schnelligkeit	NIST-Status	Verwenden für
AES-128-GCM	Symmetrische Blockchiffre (AEAD)	128 Bits	128-Bit (Post-Quantum: ~64-Bit)	Sehr schnell (hardwarebeschleunigt)	Genehmigt; FIPS 197	Daten im Ruhezustand, TLS-Sitzungsverschlüsselung
AES-256-GCM	Symmetrische Blockchiffre (AEAD)	256 Bits	256-Bit (Post-Quantum: ~128-Bit)	Schnell (hardwarebeschleunigt)	Genehmigt; FIPS 197; CNSA 2.0 für die nationale Sicherheit erforderlich	Daten im Ruhezustand, Daten während der Übertragung, Daten mit höchster Sensibilität
ChaCha20-Poly1305	Symmetrische Stromchiffre (AEAD)	256 Bits	256-bit	Sehr schnell (keine Hardwarebeschleunigung erforderlich)	Genehmigt; verwendet in TLS 1.3	TLS-Sitzungsverschlüsselung; Mobilgeräte und IoT-Geräte, bei denen AES-NI nicht verfügbar ist
RSA-2048	Asymmetrisch (öffentlicher Schlüssel)	2048-Bit-Modul	112-bit	Langsam für die Unterzeichnung; schnell für die Verifizierung	Genehmigt bis 2030; nach 2030 gemäß NIST IR 8547 als veraltet vorgesehen.	TLS-Zertifikate, Schlüsselaustausch (veraltet); Codesignatur (Minimum)
RSA-3072	Asymmetrisch (öffentlicher Schlüssel)	3072-Bit-Modul	128-bit	Langsamer als RSA-2048	Genehmigt; empfohlen für neue RSA-Implementierungen	Neue RSA-basierte Zertifikats- und Signaturinfrastruktur
ECDSA P-256	Asymmetrisch (elliptische Kurve)	256-Bit-Punkt	128-bit	Schnell	Genehmigt; FIPS 186-5	TLS-Zertifikate, Codesignierung, digitale Signaturen (bei Neuinstallationen gegenüber RSA-3072 bevorzugt)
3DES (Triple DES)	Symmetrische Blockchiffre	168 Bit nominal (112 Bit effektiv)	112 Bit effektiv (Sweet32-Angriff auf 64-Bit-Blockgröße)	langsam	Für neue Anwendungen nicht mehr empfohlen (NIST SP 800-131A Rev. 2, 2019)	Nur für die Legacy-Verifizierung; nicht für neue Verschlüsselung verwenden.
DES	Symmetrische Blockchiffre	56 Bits	Weniger als 56 Bit (vollständige Schlüsselsuche möglich)	langsam	Nicht genehmigt; nicht zulässig	Verwenden Sie keine

Leistung: Was in der Praxis zählt

Die Leistungsfähigkeit des Algorithmus ist zwar relevant, aber für die meisten Organisationen selten der primäre Entscheidungsfaktor. Moderne Prozessoren mit AES-NI-Hardwarebeschleunigung (AES Native Instructions) führen AES-256-GCM so schnell aus, dass die Algorithmusleistung in der Regel kein Flaschenhals für die Datenverschlüsselung im Ruhezustand oder während der Übertragung ist, selbst bei hohem Datendurchsatz. Die in der Praxis relevanten Leistungsdimensionen sind:

• Symmetrische Verschlüsselung (AES-256-GCM vs. ChaCha20-Poly1305): Auf Hardware mit AES-NI ist AES-256-GCM in der Regel schneller. Auf Mobilgeräten oder IoT-Hardware ohne AES-NI ist ChaCha20-Poly1305 deutlich schneller. TLS 1.3 unterstützt beide Protokolle und wählt die Protokollierungsgeschwindigkeit basierend auf den Fähigkeiten von Client und Server aus.
• Asymmetrische Operationen (RSA vs. ECC): Die RSA-Verifizierung (Operation mit öffentlichem Schlüssel) ist schnell; die RSA-Signierung (Operation mit privatem Schlüssel) ist langsam. Die ECDSA-P-256-Signierung ist bei gleicher Sicherheitsstärke deutlich schneller als die RSA-3072-Signierung, was für die Codesignierung mit hohem Durchsatz oder die Zertifikatsausstellung relevant ist. Die ECDSA-Verifizierung ist etwas langsamer als die RSA-Verifizierung.
• Auswirkungen der Tastengröße auf Speicherplatz und Bandbreite: Ein RSA-3072-Zertifikat ist bei vergleichbarer Sicherheit etwa sechsmal größer als ein ECC-P-256-Zertifikat. Bei DNSSEC (wo Antworten in UDP-Pakete passen müssen) und mobilen Anwendungen (wo Bandbreite und Latenz wichtig sind) reduzieren ECC-Schlüsselgrößen den Overhead erheblich.

AES: Der Standard für symmetrische Verschlüsselung

AES (Advanced Encryption Standard) wurde 2001 nach einem öffentlichen Wettbewerb vom NIST ausgewählt und ist in FIPS 197 definiert. Es ist der allgemein anerkannte Standard für symmetrische Verschlüsselung in Behörden, Finanzdienstleistungsunternehmen, im Gesundheitswesen und den meisten anderen Branchen. AES ist ein Blockchiffre, der 128-Bit-Blöcke mithilfe von Substitutions-Permutations-Operationen in Runden verarbeitet.

Schlüsselgröße	Runde	Sicherheitsstärke	Anwendungsfall
128 Bits	10	128 Bit (nach Quantenintegration ca. 64 Bit mit Grover-Technologie)	Standardmäßige Datenverschlüsselung; TLS-Sitzungsschlüssel
192 Bits	12	192-bit	Geheime Informationen der Stufe „Geheim“ (US-Regierung)
256 Bits	14	256 Bit (nach Quantenintegration ca. 128 Bit mit Grover-Technologie)	Daten mit höchster Sensibilität; CNSA 2.0-Anforderung; Standardempfehlung für neue Implementierungen

Der AES-Verschlüsselungsprozess besteht aus vier Operationen, die in jeder Runde angewendet werden: SubBytes (nichtlineare Byte-Substitution mithilfe der S-Box), ShiftRows (zyklische Byte-Verschiebung innerhalb der Zeilen der 4×4-Zustandsmatrix), MixColumns (lineare Mischung über Spalten zur Diffusion) und AddRoundKey (XOR-Verknüpfung mit dem aus dem Chiffrierschlüssel abgeleiteten Rundenschlüssel). In der letzten Runde wird MixColumns ausgelassen. Die Entschlüsselung wendet die Umkehrung jeder Operation in umgekehrter Reihenfolge an.

Algorithmusauswahl: Welcher Algorithmus eignet sich für welchen Anwendungsfall?

Anwendungsfall	Empfohlener Algorithmus	Vermeiden	Literaturhinweis
Ruhende Daten (Datenbanken, Dateisysteme, Backups)	AES-256-GCM	DES, 3DES, AES-ECB (ohne Integrität), AES-CBC ohne MAC	NIST SP 800-111; FIPS 197
Datenübertragung (TLS)	TLS 1.3 mit AES-256-GCM oder ChaCha20-Poly1305; ECDHE-Schlüsselaustausch	SSL 3.0, TLS 1.0/1.1, RC4, 3DES-Verschlüsselungssammlungen	NIST SP 800-52 Rev. 2
Digitale Signaturen und Zertifikate	ECDSA P-256 (bevorzugt) oder RSA-3072 (Minimum für neue RSA); RSASSA-PSS für RSA	RSA-1024, RSA-2048 für neue, langlebige Infrastruktur, DSA	NIST FIPS 186-5; NIST IR 8547
Schlüsselaustausch / Kapselung	ECDH P-256 oder X25519; Post-Quanten: ML-KEM (FIPS 203)	RSA-Schlüsselaustausch (ohne Vorwärtsgeheimhaltung); statisches DH	NIST SP 800-56A Rev. 3; FIPS 203
Hashing (Integrität, Signaturen)	SHA-256 oder SHA-384	MD5, SHA-1 (beide wegen Kollisionsresistenz geknackt)	NIST FIPS 180-4; NIST SP 800-131A
Mobilgeräte und IoT (ohne AES-NI-Hardware)	ChaCha20-Poly1305 für die Verschlüsselung; Ed25519 für Signaturen	DES, RC4, schwache Verschlüsselungssuiten	RFC 8439 (ChaCha20-Poly1305); RFC 8032 (Ed25519)
Postquantenmigration (asymmetrisch)	ML-KEM (FIPS 203) für den Schlüsselaustausch; ML-DSA (FIPS 204) für Signaturen	RSA und ECC allein für neue, langlebige Infrastruktur	NIST FIPS 203, 204, 205; NIST IR 8547

Einsatzbeispiel: Mehrschichtige Verschlüsselung im Finanzdienstleistungssektor

Eine Finanzdienstleistungsorganisation, die Kundenfinanzdatensätze und Transaktionsdaten verschlüsselt, implementiert den folgenden Algorithmenstapel:

1. Ruhende Daten (Datenbankfeldverschlüsselung): AES-256-GCM mit datensatzspezifischen Verschlüsselungsschlüsseln (DEKs). Jeder DEK ist mit einem im HSM gespeicherten Schlüsselverschlüsselungsschlüssel (KEK) versehen. Das HSM führt die Entschlüsselungsoperationen des Schlüssels intern durch; der KEK gelangt niemals in den Anwendungsspeicher.
2. Ruhende Daten (vollständige Datenbankverschlüsselung): AES-256-CBC mit HMAC-SHA-256 (zur Kompatibilität mit der nativen Verschlüsselungsfunktion der Datenbank, die GCM nicht unterstützt). Für die sensibelsten Felder (Kontonummern, Sozialversicherungsnummern), bei denen eine Integritätsprüfung pro Datensatz erforderlich ist, wird AES-256-GCM auf Feldebene verwendet.
3. Datenübertragung (öffentlich zugängliche Webanwendungen): TLS 1.3 mit der AES-256-GCM-Verschlüsselungssuite. Der ECDHE-P-256-Schlüsselaustausch gewährleistet Vorwärtsgeheimhaltung. TLS-Zertifikate verwenden ECDSA P-256, wodurch die Zertifikatsgröße und die TLS-Handshake-Zeit im Vergleich zu RSA-2048-Zertifikaten reduziert werden.
4. Datenübertragung (interne Dienst-zu-Dienst-APIs): Mutual TLS (mTLS) mit derselben TLS 1.3-Konfiguration. Sowohl Client als auch Server verfügen über ECDSA P-256-Zertifikate, die die kryptografische Authentifizierung beider Seiten der Verbindung gewährleisten.
5. Codesignierung für Software-Releases: RSASSA-PSS mit SHA-256 und RSA-3072, Signierung innerhalb eines HSM durchgeführt mit CodeSign SecureDer private Signaturschlüssel verlässt niemals das HSM.
6. PQC-Planung: das kryptografische Inventar der Organisation (erstellt mit CBOM Secure) identifiziert alle RSA- und ECC-Instanzen. Ein gestaffelter Migrationsplan priorisiert langlebige Zertifikatshierarchien und Codesignaturinfrastrukturen für die Migration zu ML-DSA (FIPS 204) bis 2027.

Schlüsselmanagement: Der eigentliche Faktor für die Effektivität der Verschlüsselung

Die Stärke eines Verschlüsselungsalgorithmus ist wertlos, wenn die Schlüssel kompromittiert werden. Eine Organisation, die AES-256-GCM verwendet und den Schlüssel in einer Klartext-Konfigurationsdatei auf demselben Server wie die verschlüsselten Daten speichert, bietet in der Praxis nahezu denselben Schutz wie eine Organisation ohne Verschlüsselung: Jeder Angreifer, der die verschlüsselten Daten liest, kann auch den Schlüssel lesen. Best Practices für das Schlüsselmanagement bei der Datenverschlüsselung in Organisationen:

• Schlüssel und verschlüsselte Daten trennen: Verschlüsselungsschlüssel dürfen nicht am selben Ort wie die zu schützenden Daten gespeichert werden. Verwenden Sie einen dedizierten Schlüsselverwaltungsdienst (KMS) oder ein Hardware-Sicherheitsmodul (HSM) zum Speichern und Verwalten von Verschlüsselungsschlüsseln. Siehe HSM als Service für hardwaregestützte Schlüsselspeicherung.
• Verwenden Sie die Umschlagverschlüsselung: Einzelne Datensätze oder Dateien werden mit einem Datenverschlüsselungsschlüssel (DEK) verschlüsselt, und der DEK wird anschließend mit einem im KMS/HSM gespeicherten Schlüsselverschlüsselungsschlüssel (KEK) verschlüsselt. Dadurch wird die Schlüsselrotation von der Datenneuverschlüsselung entkoppelt: Die Rotation des KEK ist operativ wesentlich einfacher als die Neuverschlüsselung großer Datensätze.
• Kryptoperioden definieren und Schlüsselrotation erzwingen: NIST SP 800-57 definiert empfohlene Kryptoperioden für verschiedene Schlüsseltypen. Symmetrische Datenverschlüsselungsschlüssel: zwei bis drei Jahre, abhängig vom Datenvolumen. RSA-Privatschlüssel: ein bis drei Jahre. Die Rotation erfordert entweder die erneute Verschlüsselung der Daten mit dem neuen DEK oder (bei der Envelope-Verschlüsselung) das erneute Verpacken des DEK mit dem neuen KEK.
• Inventarisierung aller kryptografischen Assets: Organisationen können nur das schützen, was sie erfasst haben. CBOM Secure Erkennt alle in Ihrer Umgebung eingesetzten Verschlüsselungsschlüssel, Zertifikate und Algorithmen, einschließlich Schattenimplementierungen und Legacy-Algorithmen, die möglicherweise von einzelnen Entwicklungsteams ohne zentrale Aufsicht eingesetzt wurden.

Einschränkungen und Kompromisse

• Stärkere Algorithmen sind nicht immer schneller: AES-256 verwendet 14 Runden, AES-128 hingegen nur 10; die zusätzlichen Runden verursachen einen höheren Rechenaufwand. Auf Hardware mit AES-NI-Beschleunigung ist der Unterschied für die meisten Anwendungen vernachlässigbar. Auf Hardware ohne AES-NI-Beschleunigung kann AES-256 30–40 % langsamer sein als AES-128.
• Asymmetrische Algorithmen eignen sich nicht für die Massenverschlüsselung: RSA- und ECC-Verfahren sind um Größenordnungen langsamer als AES, wenn es um die Verschlüsselung großer Datenmengen geht. Asymmetrische Verschlüsselung wird für kleine Datenelemente (Schlüssel, Signaturen, Zertifikate) verwendet, während symmetrische Verschlüsselung große Datenmengen verarbeitet. Der Versuch, RSA für die Massenverschlüsselung großer Dateien einzusetzen, führt zu unpraktisch langsamen Verschlüsselungsgeschwindigkeiten.
• GCM-Authentifizierungstag-Grenzen: AES-GCM verwendet eine 96-Bit-Nonce (Initialisierungsvektor). Wird die Nonce mit demselben Schlüssel wiederholt, ist die GCM-Authentifizierung ungültig, und sowohl die Vertraulichkeit als auch die Integrität zuvor verschlüsselter Daten können gefährdet sein. Die Nonce-Verwaltung ist daher von entscheidender Bedeutung: Nonces dürfen niemals mit demselben GCM-Schlüssel wiederverwendet werden. Schlüsselrotation und Nonce-Zähler pro Schlüssel gewährleisten dies.
• Algorithmenübergänge verursachen Betriebskosten: Die Migration von einem Algorithmus zu einem anderen erfordert die erneute Verschlüsselung vorhandener Daten, die Aktualisierung aller Systeme, die diese Daten lesen und schreiben, sowie die Rotation aller zugehörigen Schlüssel und Zertifikate. Die PQC-Migration ist für Organisationen mit einer großen RSA/ECC-Infrastruktur ein mehrjähriges Programm und keine einmalige Aktion.

Fazit

Die Auswahl des Verschlüsselungsalgorithmus ist der Ausgangspunkt, nicht das Ende. AES-256-GCM für ruhende Daten, TLS 1.3 mit ECDHE für übertragene Daten und ECDSA P-256 oder RSA-3072 für Signaturen bilden den aktuellen Standard für neue Implementierungen. Der Algorithmusvergleich in diesem Beitrag bietet die Grundlage für diese Auswahl; die Schlüsselverwaltungspraktiken , die diese Schlüssel schützen, entscheiden darüber, ob die Verschlüsselung tatsächlich den gewünschten Schutz bietet. Organisationen, die den Status ihrer aktuellen Algorithmusimplementierung und etwaige Lücken ermitteln möchten, sollten mit einer kryptografischen Bestandsaufnahme beginnen. Wenn Sie Beratung zur Auswahl von Verschlüsselungsalgorithmen, zur Schlüsselverwaltungsarchitektur oder zur PQC-Migrationsplanung benötigen, wenden Sie sich an Encryption Consulting . Weiterführende Informationen finden Sie in unserem Beitrag zu symmetrischer vs. asymmetrischer Verschlüsselung.

Häufig gestellte Fragen

Welchen Verschlüsselungsalgorithmus sollten Organisationen für ruhende Daten verwenden?

AES-256-GCM ist der empfohlene Algorithmus. Er bietet eine Sicherheitsstärke von 256 Bit, authentifizierte Verschlüsselung (Erkennung von Manipulationen durch ein GCM-Authentifizierungs-Tag), Unterstützung für Hardwarebeschleunigung und ist vom NIST (FIPS 197) zugelassen sowie von CNSA 2.0 für nationale Sicherheitssysteme vorgeschrieben. Für weniger sensible Daten ist auch AES-128-GCM akzeptabel.

Worin besteht der Unterschied zwischen symmetrischer und asymmetrischer Verschlüsselung?

Symmetrische Verschlüsselung verwendet denselben Schlüssel für Ver- und Entschlüsselung (AES, ChaCha20) und ist schnell bei großen Datenmengen. Asymmetrische Verschlüsselung verwendet ein Schlüsselpaar (RSA, ECC) – einen öffentlichen Schlüssel für die Verschlüsselung und einen privaten Schlüssel für die Entschlüsselung – und ist langsamer, löst aber das Problem der Schlüsselverteilung. In der Praxis werden beide Verschlüsselungsmethoden kombiniert: Die asymmetrische Verschlüsselung erzeugt und tauscht sicher einen symmetrischen Sitzungsschlüssel für die Verschlüsselung großer Datenmengen aus.

Ist AES-256 quantensicher?

AES-256 bietet gegenüber Grovers Quantenalgorithmus eine effektive Sicherheit von etwa 128 Bit, was vom NIST als ausreichend angesehen wird. AES-128 ist anfälliger (effektive Sicherheit nach der Quantenumwandlung etwa 64 Bit). RSA und ECC sind nicht quantensicher: Shors Algorithmus kann sie knacken. Das NIST hat standardisierte Alternativen für asymmetrische Algorithmen nach der Quantenumwandlung entwickelt (ML-KEM/FIPS 203, ML-DSA/FIPS 204).

Warum wird 3DES als veraltet eingestuft?

3DES bietet nur eine effektive Sicherheit von 112 Bit (der Meet-in-the-Middle-Angriff reduziert sie von der nominellen Schlüssellänge von 168 Bit), und seine Blockgröße von 64 Bit macht es anfällig für den Sweet32-Birthday-Bound-Angriff bei Verbindungen mit langer Dauer. Das NIST hat 3DES in SP 800-131A Rev. 2 (2019) offiziell für neue Anwendungen als veraltet eingestuft. Verwenden Sie stattdessen AES.

Wann sollte ECC anstelle von RSA verwendet werden?

ECC P-256 bietet 128-Bit-Sicherheit mit einem 32-Byte-Schlüssel im Vergleich zum 384-Byte-Schlüssel von RSA-3072. ECC ist die bevorzugte Lösung für TLS-Zertifikate (kleinere Zertifikatsgrößen), Codesignierung (kleinere Signaturen), Mobilgeräte und IoT (geringerer Rechenaufwand) sowie DNSSEC. Verwenden Sie RSA, wenn Kompatibilität mit älteren Systemen erforderlich ist; ansonsten ist ECC die bessere Wahl für neue Implementierungen.

Was ist AES-GCM und warum wird es gegenüber AES-CBC bevorzugt?

AES-GCM bietet authentifizierte Verschlüsselung: Es verschlüsselt Daten und enthält ein GCM-Authentifizierungs-Tag, das jede Änderung am Chiffretext erkennt. AES-CBC bietet lediglich Vertraulichkeit ohne Integritätsprüfung. Bei fehlerhafter Implementierung ist AES-CBC zudem anfällig für Padding-Oracle-Angriffe. Gemäß NIST SP 800-38D wird AES-GCM für alle neuen Implementierungen symmetrischer Verschlüsselung empfohlen.