Welche Verschlüsselungsstandards sind heute relevant? AES, RSA, ECC und Hash-Verfahren im Vergleich

Kryptografische Grundbegriffe: Verschlüsselung, Signatur, Hash und warum Kodierung etwas anderes ist

Kryptografie wird im Alltag oft als Sammelbegriff verwendet, obwohl unterschiedliche Verfahren unterschiedliche Ziele verfolgen. Verschlüsselung schützt Vertraulichkeit, Signaturen sichern Authentizität und Integrität, Hash-Funktionen liefern eindeutige Prüfsummen-Eigenschaften ohne „Entschlüsselbarkeit“. Zusätzlich existiert Kodierung (Encoding) als rein technische Darstellung von Daten, die keine Sicherheitsgarantie liefert. Eine saubere Begriffsabgrenzung verhindert typische Architekturfehler, etwa wenn ein Base64-kodiertes Token fälschlich als „verschlüsselt“ gilt oder wenn ein schneller Hash zur Passwortspeicherung eingesetzt wird.

Verschlüsselung: Vertraulichkeit durch Schlüssel und Betriebsarten

Verschlüsselung transformiert Klartext mithilfe eines Schlüssels in Geheimtext. Nur wer den passenden Schlüssel besitzt (oder bei asymmetrischen Verfahren den passenden privaten Schlüssel), kann wieder auf den Klartext zugreifen. Symmetrische Verfahren wie AES nutzen denselben geheimen Schlüssel für Ver- und Entschlüsselung; sie sind sehr schnell, erfordern aber eine sichere Schlüsselverteilung. Asymmetrische Verfahren wie RSA oder ECC trennen öffentlichen und privaten Schlüssel und eignen sich dadurch für Schlüsselaustausch, Identitäten und Signaturen, sind jedoch rechenintensiver.

In der Praxis hängt die Sicherheit nicht nur vom Algorithmus ab, sondern ebenso von Parametern und Betriebsarten. Bei Blockchiffren entscheidet der Modus über zentrale Eigenschaften: Authenticated Encryption (z. B. AES-GCM oder ChaCha20-Poly1305) liefert Vertraulichkeit und Integrität in einem Konstrukt. Ohne Authentifizierung kann ein Angreifer Inhalte oft manipulieren, selbst wenn er sie nicht lesen kann. Ebenso kritisch sind Initialisierungsvektoren/Nonces: Sie müssen je nach Modus eindeutig und korrekt erzeugt werden; Wiederverwendung kann katastrophale Folgen haben, insbesondere bei GCM.

Digitale Signaturen: Authentizität, Integrität und Nichtabstreitbarkeit

Eine digitale Signatur belegt, dass eine Nachricht (oder ein Dokument) unverändert ist und von einem Besitzer des privaten Schlüssels stammt. Technisch wird dabei üblicherweise nicht der gesamte Inhalt „signiert“, sondern ein Hash des Inhalts; signiert wird dann dieser Hashwert. Verifikation erfolgt mit dem zugehörigen öffentlichen Schlüssel. Signaturen verschlüsseln nicht: Der Inhalt bleibt im Klartext, sofern nicht zusätzlich eine Verschlüsselungsschicht genutzt wird.

Im TLS-Ökosystem signieren Zertifizierungsstellen (CAs) Zertifikate, um Bindungen zwischen Domainnamen und öffentlichen Schlüsseln zu bestätigen. Der Server weist im Handshake nach, dass er den privaten Schlüssel zum Zertifikat besitzt. Moderne TLS-Versionen nutzen für den Schlüsselaustausch typischerweise (EC)DHE für Forward Secrecy; das Zertifikat dient primär der Authentisierung, nicht der direkten Datenverschlüsselung mit RSA. Dadurch bleibt die Vertraulichkeit vergangener Sitzungen auch dann geschützt, wenn der langfristige Serversignaturschlüssel später kompromittiert wird.

Hash-Funktionen: Einweg-Abbildung mit definierten Sicherheitseigenschaften

Kryptografische Hash-Funktionen bilden Eingaben beliebiger Länge auf Ausgaben fester Länge ab. Wichtige Eigenschaften sind Präbildresistenz (aus dem Hash keinen Eingang rekonstruieren), Zweitpräbildresistenz (zu einer gegebenen Nachricht keine andere mit gleichem Hash finden) und Kollisionsresistenz (keine zwei unterschiedlichen Nachrichten mit gleichem Hash finden). Hashes eignen sich für Integritätsprüfungen, Signaturen (als Vorverarbeitung) und als Baustein in Protokollen, ersetzen aber keine Verschlüsselung.

Für Passwortspeicherung gelten andere Anforderungen als für allgemeine Integritäts-Hashes. Schnelle Funktionen wie SHA-256 sind für Passwörter ungeeignet, weil Angreifer Milliarden Kandidaten pro Sekunde testen können. Stattdessen kommen absichtlich langsame, parameterisierbare Verfahren mit Salt zum Einsatz, häufig als Key-Derivation-Function (KDF) oder speziell als Passwort-Hash. Argon2id (Gewinner der Password Hashing Competition) und bcrypt sind gängige Optionen; scrypt ist ebenfalls verbreitet. Entscheidend sind ein eindeutiger Salt pro Passwort und eine Konfiguration, die Kosten für Offline-Angriffe erhöht und sich an neue Hardware anpassen lässt.

Kodierung (Encoding) und Kompression: Transport- und Speicherformate ohne Sicherheitswirkung

Kodierung transformiert Daten, um sie in einem bestimmten Kanal darstellbar zu machen, etwa als ASCII-kompatible Zeichenfolge. Base64, URL-Encoding oder JSON-Escaping sind reversible Darstellungen ohne Geheimnis. Wer die Kodierung kennt, kann die Originaldaten sofort wiederherstellen; ein Schlüssel existiert nicht. Kompression (z. B. DEFLATE, Brotli) reduziert die Größe, hat aber ebenfalls keine kryptografische Schutzfunktion. In Sicherheitskontexten führt die Verwechslung häufig zu Datenlecks, etwa wenn API-Token lediglich base64-kodiert gespeichert oder übertragen werden.

Häufige Missverständnisse und praktische Leitplanken

• „Base64 ist Verschlüsselung“: Base64 ist eine Kodierung; jede Partei kann ohne Schlüssel dekodieren. Geheimhaltung entsteht erst durch Verfahren wie AES-GCM oder durch Transportabsicherung via TLS.
• „Hashen entspricht Verschlüsseln“: Ein Hash ist nicht umkehrbar; er schützt keine Vertraulichkeit. Für vertrauliche Daten ist Verschlüsselung erforderlich, für Integrität ein Hash oder besser ein authentifiziertes Konstrukt wie HMAC bzw. AEAD.
• Passwortspeicherung mit schnellen Hashes: SHA-256 oder SHA-512 ohne KDF sind für Passwörter ungeeignet. Üblich sind Argon2id, bcrypt oder scrypt mit individuellem Salt; Parameter (Zeit-/Speicheraufwand) müssen regelmäßig überprüft werden.
• „Signatur verschlüsselt den Inhalt“: Signaturen belegen Herkunft und Unverändertheit, verbergen aber keinen Inhalt. Vertraulichkeit entsteht erst durch zusätzliche Verschlüsselung oder durch einen geschützten Transportkanal.
• Integrität ohne Authentizität: Ein nackter Hash (z. B. SHA-256) verhindert keine Manipulation, wenn ein Angreifer den Hash mit austauschen kann. Für Authentizität ist ein geheimer Schlüssel (HMAC) oder eine Signatur notwendig.

Diese Unterscheidungen wirken sich unmittelbar auf Systemdesign aus: Für gespeicherte Daten (Data-at-Rest) zählt Schlüsselverwaltung, Rotationsstrategie und die Trennung von Daten und Schlüsseln. Für Datenübertragung (Data-in-Transit) ist neben starker Kryptografie die korrekte Protokollauswahl entscheidend, etwa TLS mit zeitgemäßen Cipher Suites, verlässlicher Zertifikatsprüfung und abgesicherter Namensvalidierung. Ohne diese Grundlagen bleibt die Diskussion über AES, RSA, ECC oder Hash-Verfahren reine Theorie.

Vergleichstabellen zu AES, RSA, ECC und Hash-Verfahren: Parameter, Sicherheitsniveau, Performance und typische Einsatzfälle

Vergleichstabellen helfen, Kryptoverfahren anhand messbarer Parameter einzuordnen: Sicherheitsniveau (in der Praxis meist als „Bit-Sicherheitsäquivalent“ kommuniziert), typische Schlüssellängen, Performance-Eigenschaften sowie Eignung für Anwendungsfälle wie Datenverschlüsselung, Schlüsselaustausch, Signaturen oder Integritätsprüfungen. Wichtig ist die Trennung zwischen Verfahren zur Vertraulichkeit (Verschlüsselung), zur Authentizität/Integrität (Signaturen, MACs) und reinen Einwegfunktionen (Hashing).

Symmetrisch vs. asymmetrisch vs. Hash: Einordnung in einer Tabelle

Symmetrische Algorithmen wie AES arbeiten mit demselben Geheimnis für Ver- und Entschlüsselung und sind für große Datenmengen sehr schnell. Asymmetrische Verfahren wie RSA und ECC trennen öffentlichen und privaten Schlüssel; sie eignen sich für Schlüsselaustausch und Signaturen, sind jedoch rechenintensiver. Hash-Verfahren wie SHA-2/SHA-3 erzeugen Prüfsummen fester Länge und liefern keine Entschlüsselbarkeit; sie dienen als Baustein für Integrität, Signaturen, Key-Derivation oder Passwort-Hashing (mit speziell dafür vorgesehenen Verfahren).

Parameter, die den Sicherheitswert in der Praxis dominieren

Die reine Nennung eines Algorithmus reicht selten. Bei AES entscheidet der Betriebsmodus über Vertraulichkeit und Integrität: Authenticated Encryption (z. B. GCM) verhindert nicht nur Mitlesen, sondern erkennt Manipulation. Bei RSA hängt die Sicherheit im Encryption-Kontext zwingend an sicherem Padding; „RSA ohne OAEP“ gilt als Fehlkonfiguration. Bei ECC beeinflussen Kurvenauswahl, Implementierungsqualität und Side-Channel-Schutz die reale Sicherheit ebenso wie die mathematische Stärke. Für Hash-Verfahren ist die Frage entscheidend, ob Kollisionsresistenz (z. B. für Signaturen) oder Präbildresistenz (z. B. für Integritätsprüfungen) benötigt wird.

• AES-Moduswahl: Für neue Designs gilt AES-GCM oder ChaCha20-Poly1305 als Standard für AEAD; AES-CBC erfordert zusätzlich einen sicheren MAC (z. B. HMAC-SHA-256) und korrekte Reihenfolge (Encrypt-then-MAC).
• Nonce/IV-Disziplin: Bei AEAD ist Wiederverwendung kritisch; in AES-GCM darf ein Nonce pro Schlüssel nicht wiederholt werden, da sonst Authentizität und teils Vertraulichkeit kollabieren.
• RSA-Padding: Für Verschlüsselung/Key-Encapsulation ist RSA-OAEP relevant, für Signaturen RSA-PSS; alte Konstrukte wie „PKCS#1 v1.5 Encryption“ gelten als risikobehaftet und werden in modernen Profilen vermieden.
• ECC-Schlüssel und Kurven: Häufige TLS-Kurven sind secp256r1 (P-256) und secp384r1; für Signaturen ist Ed25519 verbreitet, mit anderen Implementierungseigenschaften als ECDSA.
• Hash-Funktion vs. Passwort-Hashing: SHA-256 ist keine geeignete alleinige Passwortspeicherung; für Passwörter sind Argon2id oder bcrypt vorgesehen, optional mit systemseitigem Pepper.

Schlüssellängen-Äquivalenz: praxisnahe Orientierung

Für Management-Entscheidungen wird häufig in Sicherheitsäquivalenten gedacht: Symmetrische 128 Bit gelten im Regelfall als sehr robust; 256 Bit dienen oft als zusätzlicher Puffer, etwa bei langfristigen Schutzbedarfen oder konservativen Policies. Asymmetrische Verfahren benötigen deutlich größere Parameter, um ein ähnliches Angriffsbudget zu erfordern. Die verbreitete Faustregel ordnet 3072-Bit-RSA ungefähr in die Nähe von 128-Bit-symmetrischer Sicherheit ein, während P-256 bei ECC oft als vergleichbares Niveau betrachtet wird. Solche Äquivalenzen sind Vereinfachungen: Protokolldetails, Implementierung, Zufallszahlengüte und Side-Channel-Resistenz können den Ausschlag geben.

Performance und Einsatzfälle: warum Hybridkryptografie Standard ist

Für große Datenmengen dominiert symmetrische Kryptografie, weil Durchsatz und Latenz planbar bleiben und Hardwarebeschleunigung häufig verfügbar ist. Asymmetrische Kryptografie wird in der Regel nur für den Verbindungsaufbau genutzt: Schlüssel werden authentisiert und ausgetauscht, danach schützt ein symmetrischer Sitzungsschlüssel die Daten. In TLS ist dies als Kombination aus (EC)DHE für Forward Secrecy und AEAD für den Datenkanal etabliert. RSA spielt in Zertifikaten weiterhin eine Rolle, jedoch eher als Signaturalgorithmus des Serverzertifikats als für den eigentlichen Schlüsselaustausch.

• TLS-Schlüsselaustausch: Moderne Konfigurationen setzen auf ECDHE (oder in aktuellen Deployments auch hybride PQ/TLS-Ansätze, abhängig vom Stack), um Forward Secrecy zu erreichen; der Datenkanal nutzt AEAD wie AES-128-GCM oder ChaCha20-Poly1305.
• Signaturen in Zertifikaten: Häufig sind RSA-PSS oder ECDSA anzutreffen; Ed25519 ist in vielen Umgebungen verfügbar, kann aber je nach PKI-Tooling/Client-Mix eingeschränkt sein.
• Daten-at-Rest: Für Volume-/Dateiverschlüsselung werden Verfahren wie AES-XTS eingesetzt; Authentizität muss auf einer höheren Schicht gelöst werden, da XTS keine Integritätsgarantie liefert.
• Passwortspeicherung: Parameter werden so gesetzt, dass ein einzelner Hash spürbar Rechenzeit und bei Argon2id zusätzlich Speicher kostet; typische Stellgrößen sind time_cost, memory_cost und parallelism.

Typische Missverständnisse bei Tabellenvergleichen

Tabellen laden zu Kurzschlüssen ein, die in technischen Reviews regelmäßig auffallen. „Hash = Verschlüsselung“ ist fachlich falsch: Hashes sind nicht umkehrbar und schützen keine Vertraulichkeit. Ebenso ist „längerer Schlüssel = automatisch sicher“ unvollständig, wenn Modus, Nonce-Management oder Padding unsicher sind. Schließlich wird Kodierung (Base64, Hex) häufig fälschlich als Schutzmaßnahme interpretiert; sie ändert nur die Darstellung von Daten.

• Verschlüsselung vs. Kodierung: Base64 und URL-Encoding sind reversible Formatierungen ohne Geheimnis; sie ersetzen keine Verschlüsselung und keine Zugriffskontrolle.
• Hash vs. MAC: Ein Hash wie SHA-256 allein belegt keine Authentizität; dafür ist ein Schlüssel nötig, z. B. HMAC-SHA-256 oder AEAD (z. B. AES-GCM).
• RSA „für Datenverschlüsselung“: RSA wird in Protokollen typischerweise nicht für große Nutzdaten verwendet, sondern für Schlüsselmaterial oder Signaturen; Nutzdaten laufen über symmetrische Sitzungsschlüssel (Hybridkryptografie).
• „AES-256 ist immer besser“: AES-256 erhöht die Schlüsselgröße, kann aber in manchen Implementierungen geringfügig mehr CPU kosten; häufig ist AES-128-GCM bereits sehr stark, sofern Nonces und Schlüsselrotation korrekt gehandhabt werden.

Praxisbezug: TLS-Zertifikate, Cipher Suites, Schlüsselaustausch und Passwort-Hashing (bcrypt, scrypt, Argon2) richtig einordnen

TLS-Zertifikate: Identität, nicht „Verschlüsselung an sich“

TLS-Zertifikate werden in der Praxis oft mit „der Verschlüsselung“ gleichgesetzt. Technisch stellt ein X.509-Zertifikat jedoch primär eine signierte Identitätsaussage dar: Ein öffentlicher Schlüssel wird mit einem Namen (z. B. DNS:example.org) und Metadaten (Gültigkeitszeitraum, Key Usage, Policies) verknüpft. Die Vertrauenskette entsteht durch Signaturen einer CA bis zu einem Root-Store im Betriebssystem oder Browser. Die eigentliche Vertraulichkeit des Datenstroms liefert erst das Zusammenspiel aus Schlüsselaustausch und symmetrischer Datenverschlüsselung innerhalb der TLS-Sitzung.

Wesentlich ist die Trennung der Rollen: Signaturen in Zertifikaten dienen der Authentizität und Integrität der Identität; die Nutzdaten werden danach mit symmetrischen AEAD-Verfahren (typisch AES-GCM oder ChaCha20-Poly1305) geschützt. Der öffentliche Schlüssel im Zertifikat wird bei TLS 1.3 außerdem nicht mehr direkt für den Schlüsselaustausch genutzt, sondern überwiegend für die Signatur im Handshake; der gemeinsame Sitzungsschlüssel entsteht über (EC)DHE. Dadurch wird Forward Secrecy zum Standard, selbst wenn der private Zertifikatschlüssel später kompromittiert würde.

Cipher Suites und TLS 1.2 vs. TLS 1.3: was wirklich ausgewählt wird

„Cipher Suite“ ist je nach TLS-Version unterschiedlich zu lesen. In TLS 1.2 benennt die Suite typischerweise vier Aspekte gleichzeitig: Schlüsselaustausch (z. B. ECDHE), Authentisierung (z. B. RSA oder ECDSA), Bulk Cipher (z. B. AES-128-GCM) und Hash/PRF. In TLS 1.3 wurde das entkoppelt: Die Suite beschreibt im Kern nur noch das symmetrische AEAD-Verfahren und den Hash für HKDF; Schlüsselaustauschgruppen (z. B. X25519, secp256r1) und Signaturalgorithmen (z. B. rsa_pss_rsae_sha256, ecdsa_secp256r1_sha256) werden separat verhandelt.

In der Praxis bedeutet das: Eine „RSA-Cipher-Suite“ im Sinne von TLS 1.2 kann Schlüsselaustausch ohne Forward Secrecy implizieren (historisch TLS_RSA_WITH_...), während RSA in TLS 1.3 vor allem als Signaturalgorithmus (z. B. RSA-PSS) auftaucht. Moderne Serverkonfigurationen priorisieren ECDHE sowie AEAD und vermeiden CBC-Mode-Altlasten. Für die Kompatibilität mit älteren Clients bleibt TLS 1.2 relevant, die Sicherheitsmechanik ist jedoch komplexer und stärker konfigurationsabhängig.

Schlüsselaustausch: ECDHE als Standard, RSA nur noch für Signaturen

Der Schlüsselaustausch in modernen TLS-Setups basiert auf ephemerem Diffie-Hellman, heute meist als ECDHE mit Kurven wie X25519 oder secp256r1. Das Ziel ist ein gemeinsames Geheimnis, das weder über das Zertifikat noch über die übertragenen Handshake-Daten rekonstruierbar ist. Aus diesem Geheimnis leitet TLS mittels HKDF Sitzungsschlüssel ab; anschließend schützen AEAD-Verfahren die Nutzdaten samt Authentizität (integrierter MAC/Tag).

RSA spielt im TLS-Handschlag weiterhin eine Rolle, aber anders als in älteren Modellen: Statt den Pre-Master-Secret mit dem RSA-Zertifikat zu „verschlüsseln“, signiert der Server Handshake-Transkripte, um den Besitz des privaten Schlüssels nachzuweisen. Diese Verschiebung reduziert den Schaden bei späterem Schlüsselverlust, weil vergangene Sitzungen durch Forward Secrecy geschützt bleiben. Entscheidend bleibt eine korrekte Validierung der Zertifikatskette inklusive Hostname-Abgleich und zeitlicher Gültigkeit.

• Typischer TLS-1.3-Datenpfad: (EC)DHE erzeugt ein gemeinsames Geheimnis, daraus leitet HKDF-SHA256 oder HKDF-SHA384 Traffic-Keys ab, Nutzdaten laufen über AES-128-GCM/AES-256-GCM oder ChaCha20-Poly1305.
• Forward Secrecy (FS): FS entsteht durch ephemere Schlüssel (DHE/ECDHE). Ein später kompromittierter Zertifikatschlüssel ermöglicht dann keine Entschlüsselung alter Mitschnitte, solange die Endpunkte nicht zusätzlich kompromittiert wurden.
• Signaturen im Handshake: Authentisierung erfolgt über Signaturen (z. B. ECDSA oder RSA-PSS) auf Handshake-Daten; diese Signaturen ersetzen keine Datenverschlüsselung und sind davon getrennt zu betrachten.
• Häufige Fehlannahme: Ein Zertifikat „enthält“ keine geheimen Schlüssel. Es enthält einen öffentlichen Schlüssel und CA-Signaturen; Vertraulichkeit entsteht erst durch die ausgehandelten Sitzungsschlüssel.

Passwort-Hashing: bcrypt, scrypt, Argon2 als Speicherverfahren, nicht als Transport-Sicherheit

Passwörter werden nicht verschlüsselt, sondern als Verifikationswerte gespeichert. Dafür sind absichtlich langsame, parameterisierbare Passwort-Hashfunktionen vorgesehen, die Offline-Angriffe mit GPU/ASIC verteuern. Ein schneller Hash wie SHA-256 ist für Passwörter ungeeignet, weil er pro Sekunde extrem viele Versuche erlaubt; ein Salt allein löst dieses Problem nicht. Bewährte Verfahren sind bcrypt (CPU-hart), scrypt (speicherhart) und Argon2id (kombiniert, heute häufige Empfehlung).

Die Parameterwahl ist integraler Bestandteil der Sicherheit: Bei bcrypt bestimmt der Cost-Faktor die Rechenzeit, bei scrypt und Argon2id kommen Speicher- und Parallelitätsparameter hinzu. Ziel ist eine Verifikationszeit, die im Login-Flow akzeptabel bleibt, aber Offline-Bruteforce klar ausbremst. Zusätzlich bleibt eine serverseitige Schutzschicht sinnvoll, etwa Rate Limiting und bei Bedarf ein Pepper, der getrennt vom Datenbankinhalt verwahrt wird.

Typische Missverständnisse in produktiven Setups

In der Praxis vermischen sich Begriffe: Kodierung (z. B. Base64) ändert nur die Darstellung von Daten, bietet keine Vertraulichkeit. Hashing ist irreversibel und dient der Integrität (allgemein) oder der Passwortverifikation (spezialisiert). Verschlüsselung ist reversibel und erfordert Schlüsselmanagement. TLS nutzt alle drei Kategorien in unterschiedlichen Rollen: Base64 taucht in PEM-Dateien auf, Hashes in Signaturen und KDFs, Verschlüsselung im Record-Layer.

• Base64 ist keine Sicherheit: Ein in -----BEGIN CERTIFICATE----- dargestelltes Zertifikat ist lediglich PEM-kodiert; der Inhalt bleibt öffentlich lesbar.
• „Passwort verschlüsseln“ ist die falsche Zielsetzung: In Datenbanken sollten Passwörter als Ausgabe von bcrypt, scrypt oder Argon2id mit individuellem Salt liegen; „entschlüsseln“ darf technisch nicht möglich sein.
• TLS schützt nicht vor kompromittierten Endpunkten: TLS sichert den Transport. Bei Malware am Client oder Server werden Klartext und Schlüsselmaterial im Prozessspeicher verarbeitet und bleiben angreifbar.
• Zertifikat ersetzt keine Härtung: Ein korrektes Zertifikat verhindert keine schwachen Cipher-Policies, keine fehlenden Updates und keine Fehlkonfigurationen bei Protokollversionen oder Schlüsselgruppen.