Öffentlicher vs. privater Schlüssel: So funktioniert jedes Verfahren und wann Sie es einsetzen

Ein öffentlicher und ein privater Schlüssel sind die beiden Hälften eines Schlüsselpaars, das bei der asymmetrischen Verschlüsselung zum Einsatz kommt. Der öffentliche Schlüssel darf offen weitergegeben werden und dient dazu, Daten zu verschlüsseln oder eine digitale Signatur zu prüfen. Der private Schlüssel bleibt geheim und dient dazu, Daten zu entschlüsseln oder eine Signatur zu erzeugen. Die symmetrische Verschlüsselung funktioniert anders: Ein gemeinsamer geheimer Schlüssel verschlüsselt und entschlüsselt zugleich. Das ist schnell, wirft aber die Frage auf, wie dieser Schlüssel sicher geteilt wird. In der Praxis kombinieren Systeme beide Verfahren. Die Public-Key-Kryptografie authentifiziert die Beteiligten und richtet einen Sitzungsschlüssel ein, und eine symmetrische Chiffre wie AES-256 schützt anschließend die Daten selbst.

Keines der beiden Verfahren ist pauschal „sicherer“. Die Sicherheit hängt vom Algorithmus, von der Schlüssellänge, von der Implementierung und vor allem davon ab, wie Schlüssel erzeugt, gespeichert, rotiert und kontrolliert werden. Public-Key-Algorithmen wie RSA und die Kryptografie auf elliptischen Kurven sind zudem diejenigen, die künftigen Quantencomputern ausgesetzt sind. Deshalb hat der Übergang zu Post-Quanten-Standards bereits begonnen. Kiteworks bietet eine Control Plane für den sicheren Datenaustausch, die AES-256-Verschlüsselung mit kundeneigenen Schlüsseln anwendet, die Anbindung von Hardware-Sicherheitsmodulen unterstützt und validierte Kryptografie nutzt, um sensible Daten bei der Übertragung und im Ruhezustand zu schützen.

Diese Seite bietet allgemeine Informationen und keine Rechts- oder Compliance-Beratung. Wenn Sie wissen möchten, wie Anforderungen an Verschlüsselung und Schlüsselverwaltung auf Ihre Organisation anzuwenden sind, wenden Sie sich an Ihr Sicherheits-, Rechts- oder Compliance-Team.

Wichtigste Erkenntnisse

1. Ein öffentlicher und ein privater Schlüssel sind zwei Hälften eines Paars

Den öffentlichen Schlüssel kann jeder besitzen, den privaten Schlüssel sollte nur der Eigentümer besitzen. Daten, die mit dem öffentlichen Schlüssel verschlüsselt wurden, lassen sich nur mit dem passenden privaten Schlüssel entschlüsseln, und eine mit dem privaten Schlüssel erzeugte Signatur kann jeder prüfen, der den öffentlichen Schlüssel hat.

2. „Privater Schlüssel“ bedeutet nicht „symmetrischer Schlüssel“

In der üblichen Fachterminologie ist ein privater Schlüssel die geheime Hälfte eines asymmetrischen Schlüsselpaars, und ein symmetrischer Schlüssel heißt geheimer Schlüssel. Viele Artikel bezeichnen die symmetrische Verschlüsselung lax als „Private-Key-Verschlüsselung“, was Verwirrung darüber stiftet, welche Algorithmen und Eigenschaften wohin gehören.

3. Moderne Systeme nutzen beide Verfahren gemeinsam

Die Public-Key-Kryptografie authentifiziert und tauscht Schlüssel aus, die symmetrische Verschlüsselung schützt die Massendaten. Dieses hybride Konzept liegt TLS, SSH, S/MIME und PGP zugrunde und verbindet die Vorteile des einen bei der Schlüsselverteilung mit der Geschwindigkeit des anderen.

4. Die Schlüsselverwaltung entscheidet über die Sicherheit in der Praxis

Ein starker Algorithmus kann einen offengelegten oder schlecht kontrollierten privaten Schlüssel nicht ausgleichen. Regelwerke wie CMMC, HIPAA und die DSGVO schauen darauf, wie Schlüssel erzeugt, gespeichert, rotiert und vernichtet werden und wer sie kontrolliert.

5. Public-Key-Algorithmen stehen vor einem Quantenübergang

Quantencomputer, die den Shor-Algorithmus ausführen, könnten RSA, die Kryptografie auf elliptischen Kurven und Diffie-Hellman brechen, während AES-256 weiterhin als sicher gilt. Organisationen sollten erfassen, wo sie Public-Key-Kryptografie einsetzen, und die Migration zu Post-Quanten-Standards planen.

Was ist der Unterschied zwischen einem öffentlichen und einem privaten Schlüssel?

Ein öffentlicher Schlüssel verschlüsselt Daten oder prüft eine Signatur, und der zugehörige private Schlüssel entschlüsselt Daten oder erzeugt eine Signatur. Die beiden Schlüssel sind mathematisch verknüpft, doch wer den öffentlichen Schlüssel kennt, kann den privaten Schlüssel mit praktisch vertretbarem Aufwand nicht ableiten, sofern Algorithmus und Schlüssellänge solide sind.

Ist „Private-Key-Verschlüsselung“ dasselbe wie symmetrische Verschlüsselung?

Im Sprachgebrauch verwenden viele Quellen „Private-Key-Verschlüsselung“ (oder „Private-Key-Verfahren“) für die symmetrische Verschlüsselung, weil der gemeinsame Schlüssel privat bleiben muss. Auch im Deutschen ist diese Verwendung verbreitet, sie widerspricht jedoch der üblichen kryptografischen Fachterminologie, in der „privater Schlüssel“ die geheime Hälfte eines Schlüsselpaars in der asymmetrischen Kryptografie bezeichnet. Dieser Beitrag verwendet die Fachbegriffe: Symmetrische Verschlüsselung nutzt einen geheimen Schlüssel, und asymmetrische Verschlüsselung nutzt einen öffentlichen und einen privaten Schlüssel. AES-256 verwendet beispielsweise einen geheimen Schlüssel, keinen privaten Schlüssel. Wie die Chiffre funktioniert, erfahren Sie in unserem Leitfaden zur AES-256-Verschlüsselung.

Was ist symmetrische Verschlüsselung?

Die symmetrische Verschlüsselung nutzt zum Ver- und Entschlüsseln denselben geheimen Schlüssel. Algorithmen wie AES sind schnell und effizient, weshalb sie die meisten gespeicherten Dateien, Datenbankinhalte und den meisten Netzwerkverkehr schützen. Die Schwäche liegt in der Schlüsselverteilung: Beide Parteien brauchen denselben Schlüssel, und wer ihn über ein nicht vertrauenswürdiges Netzwerk sendet, legt ihn offen. Genau diese Einschränkung löst die Public-Key-Kryptografie.

Was ist asymmetrische Verschlüsselung (Public-Key-Verschlüsselung) und wie funktioniert sie?

Die asymmetrische Verschlüsselung nutzt ein Schlüsselpaar. Der Eigentümer erzeugt das Paar und veröffentlicht den öffentlichen Schlüssel. Um eine vertrauliche Nachricht zu senden, verschlüsselt der Absender sie mit dem öffentlichen Schlüssel des Empfängers, und nur der private Schlüssel des Empfängers kann sie entschlüsseln. Um den Absender einer Nachricht nachzuweisen, signiert der Eigentümer sie mit dem privaten Schlüssel, und jeder kann die Signatur mit dem öffentlichen Schlüssel prüfen.

Die gängigsten Algorithmenfamilien sind:

• RSA: beruht auf der Schwierigkeit, das Produkt zweier großer Primzahlen zu faktorisieren. Es unterstützt Verschlüsselung und Signaturen.
• Kryptografie auf elliptischen Kurven (ECC): beruht auf der Schwierigkeit des diskreten Logarithmusproblems auf elliptischen Kurven. Sie erreicht vergleichbare Stärke mit deutlich kürzeren Schlüsseln und wird für Signaturen (ECDSA, Ed25519) und die Schlüsselvereinbarung (ECDH, X25519) eingesetzt.
• Diffie-Hellman: ein Protokoll zur Schlüsselvereinbarung, kein Verschlüsselungsalgorithmus. Es ermöglicht zwei Parteien, über einen offenen Kanal ein gemeinsames Geheimnis abzuleiten.

Da Public-Key-Operationen langsam sind und nur kleine Eingaben verarbeiten, dienen sie dem Schutz von Schlüsseln und Hashwerten, nicht von großen Dateien.

Wie lassen sich Schlüssellängen verschiedener Algorithmen vergleichen?

Unterschiedliche Algorithmen brauchen unterschiedliche Schlüssellängen, um dieselbe Sicherheitsstärke zu erreichen. NIST SP 800-57 nennt folgende ungefähre Entsprechungen:

Schlüssellängen direkt zu vergleichen, führt in die Irre. Ein 256-Bit-ECC-Schlüssel bietet ungefähr dieselbe Stärke wie ein 3.072-Bit-RSA-Schlüssel und ein 128-Bit-AES-Schlüssel, nicht wie ein 256-Bit-AES-Schlüssel.

Wie funktionieren digitale Signaturen und Zertifikate?

Eine digitale Signatur beginnt mit einem Hashwert der Nachricht. Der Signierende signiert diesen Hashwert mit dem privaten Schlüssel, und der Empfänger prüft die Signatur mit dem öffentlichen Schlüssel. Eine gültige Signatur zeigt, dass die Nachricht vom Inhaber des privaten Schlüssels stammt und nicht verändert wurde, und in einem ordnungsgemäß geführten System unterstützt sie die Nichtabstreitbarkeit. Verschlüsselung allein bietet diese Garantien nicht, deshalb erfordern Integrität und Authentizität Signaturen, Nachrichtenauthentifizierungscodes oder authentifizierte Verschlüsselung.

Offen bleibt die Frage, woher man weiß, dass ein öffentlicher Schlüssel zu der Partei gehört, die er zu vertreten vorgibt. Eine Zertifizierungsstelle (Certificate Authority, CA) beantwortet sie, indem sie ein digitales Zertifikat ausstellt, das einen öffentlichen Schlüssel an eine Identität bindet, und dieses Zertifikat mit dem eigenen privaten Schlüssel der CA signiert. Der Zertifikatsinhaber, etwa ein Webserver, besitzt den passenden privaten Schlüssel. Browser und Betriebssysteme vertrauen einer Reihe von Root-CAs, und eine Zertifikatskette führt jedes Zertifikat auf eine davon zurück. Sperrlisten und Online-Statusabfragen erlauben es CAs, Zertifikate zurückzuziehen, deren Schlüssel kompromittiert wurden. Zusammen bilden diese Elemente eine Public-Key-Infrastruktur (PKI).

Wie arbeiten öffentliche und private Schlüssel mit AES zusammen?

Die meisten sicheren Systeme nutzen ein hybrides Konzept. Eine typische TLS-1.3-Verbindung, das Protokoll hinter HTTPS, läuft so ab:

1. Der Client kontaktiert den Server, und beide einigen sich auf Cipher Suites.
2. Sie führen einen ephemeren Diffie-Hellman-Schlüsselaustausch über eine elliptische Kurve durch, um ein gemeinsames Geheimnis abzuleiten. Weil die Schlüssel ephemer sind, lässt sich aufgezeichneter Datenverkehr später nicht entschlüsseln, falls ein langfristiger Schlüssel kompromittiert wird (Perfect Forward Secrecy, Vorwärtsgeheimhaltung).
3. Der Server legt sein Zertifikat vor und weist den Besitz des passenden privaten Schlüssels nach, indem er den Handshake signiert. Der Client validiert die Zertifikatskette.
4. Beide Seiten leiten symmetrische Sitzungsschlüssel ab, und eine authentifizierte Chiffre wie AES-GCM schützt den Rest der Sitzung.

Dasselbe Muster findet sich an anderer Stelle. SSH, IPsec-VPNs, S/MIME und PGP nutzen alle Public-Key-Kryptografie, um Parteien zu authentifizieren und einen Sitzungs- oder Nachrichtenschlüssel zu schützen oder zu vereinbaren, und eine symmetrische Chiffre, um die Daten zu schützen. Bei der Dateiverschlüsselung spricht man häufig von Envelope-Verschlüsselung: Ein zufälliger Datenschlüssel verschlüsselt die Datei, und ein Schlüsselverschlüsselungsschlüssel oder ein öffentlicher Schlüssel umhüllt den Datenschlüssel. Wie die symmetrische Hälfte im Detail funktioniert, lesen Sie in unserem Beitrag zum Schutz über AES-256 hinaus, und Praxisbeispiele für Ende-zu-Ende-Verschlüsselung zeigen den Einsatz im Alltag.

Welche Art der Verschlüsselung sollten Sie verwenden?

Sie müssen sich selten für eines von beiden entscheiden. Ordnen Sie jedes Werkzeug der passenden Aufgabe zu:

• Massendaten im Ruhezustand oder bei der Übertragung: Verwenden Sie symmetrische Verschlüsselung wie AES-256, vorzugsweise mit einem authentifizierten Modus.
• Erster Kontakt mit einer Partei, mit der Sie noch nie Schlüssel ausgetauscht haben: Verwenden Sie Public-Key-Kryptografie, um sie zu authentifizieren und einen Sitzungsschlüssel einzurichten.
• Nachweis von Herkunft oder Integrität: Verwenden Sie digitale Signaturen.
• Eine Datei an einen Empfänger senden, ohne vorab ein Geheimnis zu teilen: Verwenden Sie ein hybrides Konzept, das einen symmetrischen Datenschlüssel mit dem öffentlichen Schlüssel des Empfängers umhüllt.

Unser Leitfaden zu den Best Practices zur Datenverschlüsselung zeigt, wie Sie diese Entscheidungen auf Dateien und E-Mail anwenden.

Was ist sicherer: Public-Key-Verschlüsselung oder symmetrische Verschlüsselung?

Keines von beiden ist von Natur aus sicherer. Beide sind sicher, wenn der Algorithmus aktuell ist, die Schlüssellänge zur geforderten Stärke passt, die Implementierung solide ist und die Schlüssel gut geschützt sind. Public-Key-Algorithmen brauchen für dieselbe Stärke deutlich längere Schlüssel als symmetrische Chiffren, und sie sind diejenigen, die Quantenangriffen ausgesetzt sind. Symmetrische Schlüssel müssen dagegen sicher geteilt oder abgeleitet werden. In der Praxis gehen die meisten Vorfälle auf gestohlene Schlüssel, schwache Zufallszahlenerzeugung, falsch konfigurierte Zertifikatsprüfung oder Implementierungsfehler zurück und nicht darauf, dass die zugrunde liegende Mathematik gebrochen wurde.

Welche Bedrohungen betreffen öffentliche und private Schlüssel?

• Man-in-the-Middle-Angriffe: Ein Angreifer fängt eine Verbindung ab und gibt sich als eine der Parteien aus. Diese Angriffe gelingen, wenn die Authentifizierung fehlt oder Zertifikatsprüfungen übersprungen werden, nicht durch das Auslesen privater Schlüssel. Zertifikatsvalidierung und vertrauenswürdige CAs schützen davor. Lesen Sie mehr über Man-in-the-Middle-Angriffe.
• Brute-Force-Angriffe: Jeden möglichen Schlüssel auszuprobieren, ist bei heutigen Schlüssellängen undurchführbar, sowohl bei symmetrischen als auch bei asymmetrischen Algorithmen. Siehe Brute-Force-Angriffe.
• Kryptoanalytische Angriffe und Implementierungsangriffe: Schwächen bei Padding-Verfahren, Seitenkanäle, vorhersagbare Zufallszahlengeneratoren oder wiederverwendete Nonces können Schlüssel oder Klartext offenlegen, selbst wenn der Algorithmus solide ist.
• Schlüsselkompromittierung: Der Diebstahl eines privaten Schlüssels durch Schadsoftware, falsch konfigurierten Speicher, Zugriff von Insidern oder schwache Zugriffskontrollen erlaubt es einem Angreifer, Daten zu entschlüsseln oder sich als Eigentümer auszugeben.
• Quantencomputing: Ein ausreichend großer Quantencomputer, der den Shor-Algorithmus ausführt, könnte bei RSA, ECC und Diffie-Hellman private Schlüssel aus öffentlichen Schlüsseln ableiten. Der Grover-Algorithmus schwächt symmetrische Schlüssel nur um etwa die Hälfte ihrer Bitlänge, sodass AES-256 weiterhin als sicher gilt. Lesen Sie unsere Analyse zur Bedrohung der Verschlüsselung durch Quantencomputer.

Was sind die Best Practices für die Schlüsselverwaltung?

• Private Schlüssel in Hardware schützen. Speichern Sie sie in einem Hardware-Sicherheitsmodul (HSM) oder einem Schlüsselverwaltungsdienst und machen Sie sie nach Möglichkeit nicht exportierbar. Lesen Sie unseren Leitfaden zum Schutz von Schlüsseln mit HSM.
• Schlüssel ordnungsgemäß erzeugen. Verwenden Sie einen kryptografisch sicheren Zufallszahlengenerator und eine zugelassene Schlüssellänge.
• Schlüssel rotieren und befristen. Ersetzen Sie Schlüssel nach einem festgelegten Zeitplan und unmittelbar nach einem vermuteten Bekanntwerden. Lesen Sie über Strategien zur Rotation von Verschlüsselungsschlüsseln.
• Zugriff begrenzen. Wenden Sie das Prinzip der geringsten Rechte und die Funktionstrennung an, damit kein einzelner Administrator einen Schlüssel unbeobachtet verwenden oder exportieren kann. Lesen Sie unseren Leitfaden zu Zugriffskontrollen.
• Sicher sichern und wiederherstellen. Halten Sie geschützte Backups vor, damit Daten wiederherstellbar bleiben, und testen Sie die Wiederherstellung.
• Sperren und vernichten. Sperren Sie kompromittierte Zertifikate umgehend und vernichten Sie Schlüssel am Ende ihrer Lebensdauer.
• Festlegen, wem die Schlüssel gehören. Lesen Sie, warum kundeneigene Verschlüsselungsschlüssel für Datenschutz und Compliance wichtig sind.

Was erwarten Compliance-Regelwerke von der Schlüsselverwaltung?

• CMMC und NIST SP 800-171: verlangen kryptografische Mechanismen zum Schutz kontrollierter nicht klassifizierter Informationen bei der Übertragung (3.13.8) und im Ruhezustand (3.13.16), die Verwaltung kryptografischer Schlüssel (3.13.10) sowie FIPS-validierte Kryptografie (3.13.11). Lesen Sie, wie AES-256 die CMMC-Compliance unterstützt.
• HIPAA: behandelt Verschlüsselung als adressierbare Schutzmaßnahme, und verschlüsselte Daten können nur dann für die Safe-Harbor-Regelung bei der Meldung von Datenschutzverletzungen infrage kommen, wenn die Schlüssel geschützt bleiben. Lesen Sie unseren Leitfaden zum HIPAA-Safe-Harbor für Verschlüsselung.
• DSGVO: Art. 32 DSGVO nennt Verschlüsselung als Beispiel für eine geeignete technische Maßnahme. Die Kontrolle über die Schlüssel wirkt sich auch darauf aus, wie stark Daten ausländischen Zugriffsersuchen ausgesetzt sind.
• PCI DSS: verlangt starke Kryptografie und eine dokumentierte Schlüsselverwaltung für gespeicherte Kontodaten.
• FIPS 140-3: validiert das kryptografische Modul als Ganzes, einschließlich Schlüsselerzeugung und -speicherung, nicht nur den Algorithmus. Erfahren Sie mehr über FIPS und FIPS-Compliance auf der Kiteworks-Plattform.

Vier Fragen helfen bei der Bewertung, ob eine Architektur solide ist. Wem gehören die Schlüssel, und kann der Anbieter Ihre Daten entschlüsseln? Ist das kryptografische Modul validiert? Ist der Schlüsselaustausch mit aktuellen Protokollen geschützt, mit TLS 1.2 als Minimum und TLS 1.3 bevorzugt? Wird die Verschlüsselung durchgängig über E-Mail, Dateifreigabe, Übertragungen und APIs angewendet?

Aktueller Stand: Der Übergang zur Post-Quanten-Kryptografie

Dieser Abschnitt wird getrennt vom Rest der Seite geprüft und aktualisiert. Last reviewed: October 2026.

Das NIST hat im August 2024 seine ersten Standards für Post-Quanten-Kryptografie veröffentlicht: FIPS 203 (ML-KEM) für die Schlüsseletablierung, FIPS 204 (ML-DSA) für digitale Signaturen und FIPS 205 (SLH-DSA) als hashbasierte Signaturalternative. Sie sind dafür ausgelegt, RSA, ECC und Diffie-Hellman in den Anwendungen zu ersetzen, in denen Quantencomputer eine Bedrohung darstellen.

Die CNSA-2.0-Vorgaben der NSA legen Übergangsmeilensteine für Systeme der nationalen Sicherheit fest. Sie sehen den ausschließlichen Einsatz quantenresistenter Algorithmen für die Signierung von Software und Firmware bis 2030 und für Webbrowser, Server und Cloud-Dienste bis 2033 vor, wobei der breitere Übergang an ein US-Bundesziel für 2035 angelehnt ist. Daten mit langer Vertraulichkeitsdauer sind dem Szenario „Harvest now, decrypt later“ (jetzt sammeln, später entschlüsseln) ausgesetzt: Ein Angreifer zeichnet heute verschlüsselten Datenverkehr auf und entschlüsselt ihn, sobald ein leistungsfähiger Quantencomputer existiert. AES-256 muss nicht geändert werden.

Ein praktischer erster Schritt ist, zu erfassen, wo Ihre Systeme RSA, ECC und Diffie-Hellman einsetzen, und langlebige Daten sowie Signaturschlüssel bei der Migration zu priorisieren.

Wie Kiteworks sensible Daten mit starker Schlüsselverwaltung schützt

Kiteworks bietet eine Control Plane für den sicheren Datenaustausch, die Verschlüsselung durchgängig über E-Mail, Dateifreigabe, Managed File Transfer und APIs anwendet. Die Plattform unterstützt die oben genannten Praktiken auf folgende Weise:

• Doppelte Verschlüsselung. Jede Datei wird auf Dateiebene und erneut auf Festplattenebene verschlüsselt, jeweils mit getrennten Schlüsseln. Erfahren Sie mehr über die doppelte Verschlüsselung.
• Kundeneigene Schlüssel. Kunden besitzen ihre Verschlüsselungsschlüssel, sodass Mitarbeitende von Kiteworks die Daten eines Kunden nicht entschlüsseln können.
• HSM-Integration. Organisationen können Schlüssel außerhalb der Plattform mit unterstützten Hardware-Sicherheitsmodulen speichern und verwalten, darunter Thales Luna Network HSMs und AWS Key Management Service.
• Validierte Kryptografie. Das kryptografische Modul von Kiteworks ist unter dem NIST-CMVP-Zertifikat #4980 nach FIPS 140-3 validiert.
• Kontrollen für die Transportsicherheit. Administratoren legen die zulässigen TLS-Versionen und Cipher Suites fest und verwalten Zertifikate.
• Automatische E-Mail-Verschlüsselung. Das Kiteworks Email Protection Gateway kann ausgehende Nachrichten, die sensible Daten enthalten, verschlüsseln, und die Plattform dehnt denselben Schutz auf die E-Mail-Verschlüsselung, den sicheren Dateiaustausch und Managed File Transfer aus.

Entdecken Sie die Kiteworks Data Control Plane oder lesen Sie über SFTP und die anderen Kanäle, die sie steuert.