23. Mai 2025·8 Min
Whitfield Diffies Public‑Key‑Durchbruch für Web und Identität
Wie Whitfield Diffies Public‑Key‑Durchbruch HTTPS, sichere Nachrichten und digitale Identität möglich machte – erklärt mit Kernideen und realen Anwendungen.
Wie Whitfield Diffies Public‑Key‑Durchbruch HTTPS, sichere Nachrichten und digitale Identität möglich machte – erklärt mit Kernideen und realen Anwendungen.
Jedes Mal, wenn Sie sich bei einer Bank anmelden, etwas online kaufen oder eine private Nachricht senden, verlassen Sie sich auf eine einfache Idee: Sie können Informationen über ein Netzwerk teilen, dem andere lauschen können, und dennoch die wichtigen Teile geheim halten.
Das klingt heute offensichtlich, war aber einmal ein praktisches Chaos. Wenn zwei Personen Verschlüsselung nutzen wollten, mussten sie zuerst einen gemeinsamen geheimen Schlüssel vereinbaren. Das sicher zu tun erforderte oft einen vertrauenswürdigen Boten, ein verabredetes Treffen oder ein sicheres Firmennetzwerk—Optionen, die sich nicht auf Millionen Fremde im offenen Internet skalieren lassen.
Die Public-Key-Kryptographie änderte die Regeln. Sie führte eine Möglichkeit ein, einen Schlüssel offen zu veröffentlichen (öffentlicher Schlüssel), während ein anderer Schlüssel geheim bleibt (privater Schlüssel). Mit dieser Aufteilung kann man eine sichere Beziehung beginnen, ohne zuvor ein Geheimnis geteilt zu haben. Whitfield Diffie war eine zentrale Figur dabei, diese Erkenntnis öffentlich zu machen und zu zeigen, warum sie wichtig ist.
Wir verbinden die Kernkonzepte mit dem, was Sie tatsächlich nutzen:
Sie bekommen Erklärungen in klarem Deutsch, mit gerade genug mathematischer Intuition, um zu verstehen warum die Tricks funktionieren—ohne daraus ein Lehrbuch zu machen. Das Ziel ist, Public-Key-Krypto weniger wie Magie und mehr wie ein praktisches Werkzeug erscheinen zu lassen, das den Alltag schützt.
Vor der Public-Key-Kryptographie bedeutete sichere Kommunikation meist symmetrische Verschlüsselung: Beide Seiten verwenden denselben geheimen Schlüssel, um Nachrichten zu sperren und zu öffnen.
Stellen Sie sich ein Vorhängeschloss und einen gemeinsamen Schlüssel vor. Wenn Sie und ich Kopien desselben Schlüssels haben, kann ich eine Kiste verschließen, sie an Sie senden und Sie können sie öffnen. Das Sperren und Öffnen ist unkompliziert—vorausgesetzt, wir haben diesen Schlüssel schon.
Der Haken ist offensichtlich: Wie teilen wir den Schlüssel überhaupt sicher? Wenn ich ihn per E‑Mail schicke, kann ihn jemand abfangen. Wenn ich ihn texte, das gleiche Problem. Wenn ich ihn in einen versiegelten Umschlag lege und per Post schicke, mag das für Einzelfälle funktionieren, ist aber langsam, teuer und nicht immer zuverlässig.
Das erzeugt ein Henne‑Ei-Problem:
Symmetrische Verschlüsselung funktioniert gut, wenn nur wenige Leute beteiligt sind und es einen vertrauenswürdigen Weg gibt, Schlüssel im Voraus auszutauschen. Im offenen Internet bricht das Konzept schnell zusammen.
Stellen Sie sich eine Website vor, die mit Millionen Besuchern private Verbindungen benötigt. Mit nur symmetrischen Schlüsseln bräuchte die Website für jeden Besucher einen eigenen geheimen Schlüssel sowie einen sicheren Weg, jeden zu verteilen. Die Anzahl der Schlüssel und die Logistik ihrer Verwaltung (Erzeugung, Speicherung, Rotation, Widerruf) würden zu einer großen operativen Last.
Das heißt nicht, dass symmetrische Verschlüsselung „schlecht“ ist. Sie ist hervorragend in dem, was sie tut: schnelle, effiziente Verschlüsselung großer Datenmengen (wie den Großteil dessen, was über HTTPS gesendet wird). Die Herausforderung vor Diffie war nicht die Geschwindigkeit—es fehlte das praktische Mittel, damit Fremde ohne Vorab‑Geheimnis einen Schlüssel vereinbaren konnten.
Anfang der 1970er Jahre bedeutete sichere Kommunikation größtenteils geteilte Geheimnisse. Wenn zwei Personen Verschlüsselung nutzen wollten, brauchten sie dasselbe Geheimnis—und sie mussten einen sicheren Weg finden, es auszutauschen. Diese Annahme funktionierte in kleinen, kontrollierten Umgebungen, skaliert aber nicht zu einer Welt, in der Fremde sicher miteinander kommunizieren möchten.
Whitfield Diffie war ein junger Forscher, der sich für Privatsphäre und die praktischen Grenzen der damals bestehenden Kryptographie interessierte. Er arbeitete mit Martin Hellman an der Stanford University zusammen; ihre Arbeit wurde beeinflusst von einem wachsenden akademischen Interesse an Computersicherheit und Netzwerken—Feldern, die sich gerade von isolierten Systemen zu vernetzten Systemen entwickelten.
Das ist weniger eine Geschichte des einsamen Genies als das Zusammentreffen der richtigen Idee mit der richtigen Umgebung: Forschende verglichen Notizen, führten Gedankenexperimente durch und hinterfragten „offensichtliche“ Einschränkungen, die Jahrzehnte lang akzeptiert worden waren.
Diffie und Hellmans Durchbruch war die Idee, dass Verschlüsselung zwei verwandte Schlüssel statt eines gemeinsamen Geheimnisses verwenden kann:
Was das mächtig macht, ist nicht nur, dass es zwei Schlüssel gibt—sondern dass sie verschiedene Aufgaben haben. Der öffentliche Schlüssel ist fürs sichere Verteilen gedacht, während der private Schlüssel Kontrolle und Exklusivität ermöglicht.
Das veränderte die Sicht auf das Schlüsselverteilungsproblem. Anstatt ein geheimes Treffen (oder einen vertrauenswürdigen Kuriereinsatz) zu organisieren, um einen einzelnen geheimen Schlüssel auszutauschen, konnte man einen öffentlichen Schlüssel weit verbreiten und die Sicherheit trotzdem bewahren.
Dieser Wechsel—von „wir müssen uns zuerst treffen“ zu „wir können sicher mit öffentlichen Informationen anfangen“—ist die konzeptuelle Grundlage, die später sicheres Surfen, verschlüsselte Nachrichten und moderne digitale Identitätssysteme ermöglichte.
Diffie–Hellman (DH) ist eine clevere Methode, mit der zwei Personen dasselbe gemeinsame Geheimnis erzeugen können, selbst wenn alle ihre Nachrichten für jeden sichtbar sind. Dieses gemeinsame Geheimnis kann dann als regulärer symmetrischer Schlüssel verwendet werden, um eine Unterhaltung zu verschlüsseln.
Stellen Sie sich DH vor wie das Mischen von Zutaten auf eine Weise, die vorwärts leicht ist, aber extrem schwer „aufzumischen“ ist. Das Rezept nutzt:
Ein Lauscher kann die öffentlichen Parameter und die beiden ausgetauschten öffentlichen Werte sehen. Was er nicht praktisch tun kann, ist, entweder privaten Wert wiederherzustellen oder aus den öffentlichen Teilen das gemeinsame Geheimnis zu berechnen. Mit gut gewählten Parametern würde das Umkehren enorme Rechenressourcen erfordern.
DH verschlüsselt Nachrichten nicht selbst—es erzeugt den gemeinsamen Schlüssel, der schnelle, alltägliche Verschlüsselung möglich macht.
Public-Key‑Kryptographie funktioniert, weil einige mathematische Operationen asymmetrisch sind: Vorwärts sind sie leicht zu berechnen, aber ohne ein spezielles Geheimnis extrem schwer umzukehren.
Ein hilfreiches Modell ist die „Einwegfunktion“. Stellen Sie sich eine Maschine vor, die eine Eingabe schnell in eine Ausgabe verwandelt. Jeder kann die Maschine betreiben, aber wenn man nur die Ausgabe kennt, ist es praktisch unmöglich, die ursprüngliche Eingabe zu rekonstruieren.
In der Kryptographie verlassen wir uns nicht auf die Geheimhaltung der Maschine. Wir verlassen uns darauf, dass das Umkehren ein schwieriges Problem ist—ein Problem, von dem man annimmt, dass es einen unpraktisch hohen Rechenaufwand erfordert.
„Schwierig“ heißt nicht für immer unmöglich. Es bedeutet:
Sicherheit beruht also auf Annahmen (was Mathematikerinnen und Kryptographinnen über diese Probleme annehmen) plus praktischer Praxis (Schlüssellängen, sichere Implementierungen und aktuelle Standards).
Viel öffentliche Schlüsselmathematik passiert „modulär“—denken Sie an eine Uhr. Auf einer 12‑Stunden‑Uhr, wenn es 10 Uhr ist und Sie 5 Stunden dazurechnen, erhalten Sie nicht 15; Sie kommen bei 3 an. Dieses Verhalten ist modulare Arithmetik.
Mit großen Zahlen kann wiederholtes „Umdrehen“ zu Ausgaben führen, die wie verschlüsselt aussehen. Vorwärts (die Arithmetik) ist schnell. Rückwärts (herausfinden, womit man begonnen hat) kann schmerzhaft langsam sein, es sei denn, man kennt eine geheime Abkürzung—wie einen privaten Schlüssel.
Diese Lücke zwischen leicht vorwärts und schwer rückwärts ist der Motor hinter Schlüsselaustausch und digitalen Signaturen.
Wenn Sie das Schloss in Ihrem Browser sehen, nutzen Sie normalerweise HTTPS: eine verschlüsselte Verbindung zwischen Ihrem Gerät und einer Website. Das Web hätte nicht skaliert, wenn jeder Browser für jeden Server vorab einen geheimen Schlüssel teilen müsste.
Public-Key‑Kryptographie löst das „First‑Contact“-Problem: Sie lässt Ihren Browser sicher mit einem Server einen gemeinsamen Schlüssel vereinbaren, den er noch nie getroffen hat.
Ein moderner TLS‑Handshake ist eine schnelle Aushandlung, die Privatsphäre und Vertrauen herstellt:
Public‑Key‑Operationen sind langsamer und für Vereinbarung und Authentifizierung gedacht, nicht für große Datenmengen. Sobald TLS Sitzungsschlüssel etabliert hat, wechselt es zu schneller symmetrischer Verschlüsselung (wie AES oder ChaCha20), um alles zu schützen, was Sie wirklich senden—Seitenaufrufe, Passwörter und Cookies.
Wenn Sie den Unterschied zwischen HTTP und HTTPS in einfachen Worten wollen, siehe /blog/https-vs-http.
Eine digitale Signatur ist das Public‑Key‑Werkzeug, um eine Nachricht nachweisbar zu machen. Wenn jemand eine Datei oder Nachricht mit seinem privaten Schlüssel signiert, kann jeder die Signatur mit dem passenden öffentlichen Schlüssel prüfen.
Eine gültige Signatur beweist zwei Dinge:
Diese beiden Ideen werden oft vermischt:
Man kann das eine ohne das andere tun. Eine öffentliche Bekanntmachung kann signiert sein (damit Menschen ihr vertrauen), ohne verschlüsselt zu sein (weil sie für alle lesbar sein soll).
Digitale Signaturen tauchen an Orten auf, die Sie vielleicht täglich nutzen:
Der große Vorteil ist, dass die Überprüfung kein geteiltes Geheimnis erfordert. Der Signierende behält den privaten Schlüssel immer privat, während der öffentliche Schlüssel weit verbreitet werden kann. Diese Trennung—privat zum Signieren, öffentlich zum Verifizieren—ermöglicht es Fremden, Nachrichten in großem Maßstab zu prüfen, ohne zuvor ein Passwort oder Geheimnis auszutauschen.
Public‑Key‑Krypto löst „wie teilen wir Geheimnisse“, aber es lässt eine weitere Frage offen: Wem gehört dieser Schlüssel eigentlich? Ein öffentlicher Schlüssel allein ist nur eine lange Zahl. Man braucht eine Möglichkeit, diesen Schlüssel zuverlässig an eine reale Identität wie „meine Bank“ oder „der Mailserver dieser Firma“ zu binden.
Ein digitales Zertifikat ist ein signiertes Dokument, das so etwas aussagt wie: „Dieser öffentliche Schlüssel gehört zu dieser Identität.“ Es enthält den Seiten‑ oder Organisationsnamen (und weitere Details), den öffentlichen Schlüssel und Ablaufdaten. Der wichtige Teil ist die Signatur: Eine vertrauenswürdige Partei unterzeichnet das Zertifikat, sodass Ihr Gerät prüfen kann, ob es manipuliert wurde.
Die vertrauenswürdige Partei ist üblicherweise eine Certificate Authority (CA). Ihr Browser und Betriebssystem bringen eine eingebaute Liste vertrauenswürdiger CA‑Roots mit. Wenn Sie eine Seite besuchen, präsentiert diese ihr Zertifikat plus Zwischenzertifikate und bildet eine Vertrauenskette zurück zu einer Root‑CA, der Ihr Gerät bereits vertraut.
Wenn Sie die URL Ihrer Bank eingeben und das Schloss sehen, hat Ihr Browser geprüft, dass:
Wenn diese Prüfungen bestehen, kann TLS den öffentlichen Schlüssel sicher für Authentifizierung und zur Hilfe bei der Aufbauverschlüsselung nutzen.
PKI ist nicht perfekt. CAs können Fehler machen oder kompromittiert werden, was zu Fehlausstellungen (Zertifikat für die falsche Partei) führen kann. Zertifikate laufen ab, was für Sicherheit gut ist, aber den Zugriff unterbrechen kann, wenn sie nicht erneuert werden. Widerruf (die Welt darüber zu informieren, dass ein Zertifikat nicht mehr vertrauenswürdig ist) ist auf Internet‑Skalierung schwer umsetzbar, und Browser erzwingen Widerruf nicht immer konsequent.
Ende‑zu‑Ende‑verschlüsselte (E2EE) Nachrichten versprechen einfach: Nur die Gesprächsteilnehmer können die Nachrichten lesen. Nicht der App‑Anbieter, nicht Ihr Mobilfunkanbieter und nicht jemand, der das Netzwerk beobachtet.
Moderne Chat‑Apps versuchen, drei Ziele auszubalancieren:
Verschlüsselung braucht Schlüssel. Aber zwei Personen, die sich nie getroffen haben, sollten keinen geheimen Schlüssel im Voraus teilen müssen—sonst landen wir wieder beim ursprünglichen Schlüsselverteilungsproblem.
Public‑Key‑Kryptographie löst den Einrichtungsschritt. In vielen E2EE‑Systemen verwenden Clients einen public‑key‑basierten Austausch (im Geiste von Diffie–Hellman), um über ein unzuverlässiges Netzwerk gemeinsame Geheimnisse zu etablieren. Diese Geheimnisse speisen sich dann in schnelle symmetrische Verschlüsselung für den eigentlichen Nachrichtenverkehr.
Forward Secrecy bedeutet, dass die App nicht auf einen einzigen langlebigen Schlüssel für alles setzt. Stattdessen werden Schlüssel kontinuierlich erneuert—oft pro Sitzung oder sogar pro Nachricht—sodass das Kompromittieren eines Schlüssels nicht Ihre gesamte Historie öffnet.
Deshalb ist „Heute das Telefon stehlen, morgen Jahre an Chats entschlüsseln“ viel schwerer, wenn Forward Secrecy richtig umgesetzt ist.
Selbst mit starker Kryptographie fügt die Realität Reibung hinzu:
Unter der Haube ist sichere Nachrichtenübermittlung vor allem eine Geschichte über Schlüsselaustausch und Schlüsselmanagement—denn das verwandelt „verschlüsselt“ in „privat, selbst wenn das Netzwerk es nicht ist“.
Digitale Identität ist die Online‑Version von „wer Sie sind“, wenn Sie einen Dienst nutzen: Ihr Konto, Ihr Login und die Signale, die beweisen, dass Sie es wirklich sind (nicht jemand, der Ihr Passwort errät oder stiehlt). Jahrelang behandelten die meisten Systeme ein Passwort als diesen Beweis—einfach, vertraut und auch leicht zu phishen, wiederzuverwenden, zu leaken oder per Brute‑Force zu knacken.
Public‑Key‑Kryptographie bietet einen anderen Ansatz: Anstatt zu beweisen, dass Sie ein gemeinsames Geheimnis kennen (ein Passwort), beweisen Sie, dass Sie einen privaten Schlüssel kontrollieren. Ihr öffentlicher Schlüssel kann vom Dienst gespeichert werden, während der private Schlüssel bei Ihnen bleibt.
Beim schlüsselbasierten Login sendet der Dienst eine Challenge (ein zufälliges Stück Daten). Ihr Gerät signiert es mit Ihrem privaten Schlüssel. Der Dienst verifiziert die Signatur mit Ihrem öffentlichen Schlüssel. Kein Passwort muss über das Netz, und es gibt nichts, das ein Angreifer wiederverwenden könnte, was er aus einem Loginformular stiehlt.
Diese Idee treibt moderne „passwortlose“ Benutzererlebnisse an:
Public‑Key‑Identität funktioniert auch für Maschinen. Ein API‑Client kann Anfragen mit einem privaten Schlüssel signieren, und der Server verifiziert sie mit dem öffentlichen Schlüssel—nützlich für Service‑zu‑Service‑Authentifizierung, bei der geteilte API‑Geheimnisse schwer zu rotieren und leicht zu leaken sind.
Wenn Sie tiefer in Rollout und UX eintauchen wollen, siehe /blog/passwordless-authentication.
Public‑Key‑Kryptographie ist mächtig, aber kein Zauber. Viele reale Ausfälle passieren nicht, weil die Mathematik kaputt ist, sondern weil die Systeme drumherum es sind.
Schwache Zufallszahlen können alles zum Einsturz bringen. Wenn ein Gerät vorhersehbare Nonces oder Schlüssel erzeugt (besonders beim frühen Booten, in virtuellen Maschinen oder in eingeschränkter IoT‑Hardware), können Angreifer Geheimnisse rekonstruieren.
Fehlerhafte Implementierung ist eine weitere häufige Ursache: veraltete Algorithmen verwenden, Zertifikatsvalidierung überspringen, schwache Parameter akzeptieren oder Fehler falsch behandeln. Selbst kleine „temporäre“ Abkürzungen—wie TLS‑Checks zum Debuggen auszuschalten—gelangen oft in die Produktion.
Phishing und Social Engineering umgehen Kryptographie vollständig. Wenn ein Nutzer getäuscht wird, eine Anmeldung zu bestätigen, einen Wiederherstellungscode preiszugeben oder Malware zu installieren, helfen starke Schlüssel nicht.
Private Schlüssel müssen so gespeichert werden, dass sie nicht leicht kopiert werden können (idealerweise in sicherer Hardware) und im Ruhezustand verschlüsselt werden. Teams brauchen außerdem Pläne für Backups, Rotation und Widerruf—weil Schlüssel verloren gehen, Geräte gestohlen werden und Leute Firmen verlassen.
Wenn sichere Abläufe verwirrend sind, suchen Menschen nach Umgehungen: Konten teilen, Geräte wiederverwenden, Warnungen ignorieren oder Wiederherstellungscodes an unsicheren Orten speichern. Gutes Sicherheitsdesign reduziert Entscheidungsstellen und macht die sichere Handlung zur einfachsten.
Wenn Sie schnell Software bauen und ausliefern, ist das größte Risiko oft nicht die Kryptographie—sondern inkonsistente Konfigurationen über Umgebungen hinweg. Plattformen wie Koder.ai (eine vibe‑coding Plattform zum Erstellen von Web‑, Server‑ und mobilen Apps aus einer Chat‑Schnittstelle) können die Auslieferung beschleunigen, aber die gleichen Public‑Key‑Grundsätze gelten:
Kurz: Schnelleres Entwickeln ändert die Regeln nicht—Diffies Ideen bilden noch immer das Fundament dafür, wie Ihre App beim ersten Kontakt Vertrauen gewinnt.
Diffies Durchbruch fügte nicht nur ein neues Werkzeug hinzu—er änderte die Standardannahme der Sicherheit von „wir müssen uns zuerst treffen“ zu „wir können sicher über ein offenes Netzwerk sprechen“. Diese einzelne Verschiebung machte es praktisch, dass Milliarden Geräte und Fremde Geheimnisse erzeugen, Identitäten beweisen und Vertrauen im Internetmaßstab aufbauen.
Der ursprüngliche Diffie–Hellman‑Austausch ist weiterhin eine Grundlage, aber die meisten modernen Systeme verwenden aktualisierte Varianten.
Elliptische Kurven Diffie–Hellman (ECDH) verfolgt dasselbe Ziel—öffentlich ein gemeinsames Geheimnis vereinbaren—bei gleichzeitig kleineren Schlüsseln und schnelleren Operationen. RSA, das kurz nach Diffies Arbeit bekannt wurde, war lange Zeit berühmt für Verschlüsselung und Signaturen in der frühen Web‑Sicherheit; heute wird es vorsichtiger eingesetzt, während elliptische Kurven für Signaturen und ECDH verbreitet sind.
Fast jede reale Implementierung ist ein Hybridschema: Public‑Key‑Methoden übernehmen Handshake (Authentifizierung und Schlüsselaustausch), dann schützt schnelle symmetrische Verschlüsselung die eigentlichen Daten. Dieses Muster ermöglicht, dass HTTPS sicher und schnell zugleich ist.
Zukünftige Quantencomputer könnten heutige Public‑Key‑Techniken schwächen (besonders solche, die auf Faktorisierung und diskreten Logarithmen basieren). Der praktische Weg ist: „neue Optionen hinzufügen und sicher migrieren“, nicht sofort alles ersetzen. Viele Systeme testen post‑quantum Schlüsselaustausch und Signaturen, während sie hybride Designs beibehalten, damit Sie zusätzlichen Schutz gewinnen können, ohne alles auf einen einzigen Algorithmus zu setzen.
Auch wenn sich Algorithmen ändern, bleibt das harte Problem dasselbe: Geheimnisse und Vertrauen zwischen Parteien auszutauschen, die sich möglicherweise nie getroffen haben—schnell, global und mit möglichst wenig Nutzerfriktion.
Fazit: Public‑Key‑Krypto ermöglicht sicheren ersten Kontakt; Hybride machen es in großem Maßstab nutzbar; die nächste Ära ist eine sorgfältige Evolution.
Weiterlesen: /blog/diffie-hellman-explained, /blog/tls-https-basics, /blog/pki-certificates, /blog/post-quantum-crypto-primer
Symmetrische Verschlüsselung verwendet einen gemeinsamen geheimen Schlüssel, um zu verschlüsseln und zu entschlüsseln. Sie ist schnell und eignet sich hervorragend für große Datenmengen, hat aber ein Einrichtungsproblem: Der Schlüssel muss zuerst sicher geteilt werden.
Die Public-Key-Kryptographie trennt die Rollen in einen öffentlichen Schlüssel (teilbar) und einen privaten Schlüssel (geheim), wodurch ein „sicherer erster Kontakt“ ohne vorab geteiltes Geheimnis möglich wird.
Sie löste das Schlüsselverteilungsproblem: Zwei Fremde können sichere Kommunikation über ein beobachtbares Netzwerk beginnen, ohne sich vorher zu treffen, um ein Geheimnis auszutauschen.
Dieser Wandel macht internetweite Sicherheit praktisch für:
Diffie–Hellman (DH) ist ein Verfahren, um über einen öffentlichen Kanal ein gemeinsames Geheimnis zu erzeugen.
In der Praxis:
DH selbst verschlüsselt die Nachrichten nicht; es hilft, den Schlüssel zu vereinbaren, der das tut.
Nicht allein. Plain DH bietet Schlüsselvereinbarung, aber es beweist nicht wen Sie auf der anderen Seite haben.
Um Man-in-the-Middle-Angriffe zu verhindern, wird DH typischerweise mit Authentifizierung kombiniert, zum Beispiel:
TLS nutzt Public-Key-Kryptographie hauptsächlich für Authentifizierung und Schlüsselaustausch während des Handshakes und wechselt dann zu symmetrischen Schlüsseln für die eigentlichen Daten.
Vereinfacht:
Eine digitale Signatur erlaubt es, nachzuweisen, dass jemand etwas erstellt hat und dass es nicht verändert wurde.
Typische Anwendungen:
Man überprüft mit einem öffentlichen Schlüssel; nur der Inhaber des kann eine gültige Signatur erzeugen.
Ein Zertifikat bindet einen öffentlichen Schlüssel via Signatur an eine Identität (z. B. einen Webseiten-Namen).
Browser vertrauen Zertifikaten, weil sie eine Kette vom Seitenzertifikat über Zwischenzertifikate bis zu einer vertrauenswürdigen Root-CA bauen können, die im OS/Browser installiert ist.
Operativ ist deshalb Zertifikatsverlängerung, korrekte Hostname-Konfiguration und richtige Validierung für zuverlässiges HTTPS entscheidend.
E2E-Apps müssen erst gemeinsame Schlüssel zwischen Geräten herstellen, die sich nicht vorher getroffen haben.
Sie nutzen meist DH-artige Austausche (oft mit elliptischen Kurven), um:
Passkeys (FIDO2/WebAuthn) ersetzen das Passwort durch eine Challenge–Response-Signatur.
In der Praxis:
Das reduziert Phishing- und Wiederverwendungsrisiken, weil kein wiederverwendbares Geheimnis in ein Webseitenformular eingegeben wird.
Die meisten Ausfälle betreffen Implementierung und Betrieb, nicht die mathematische Grundlage.
Häufige Schwachstellen:
Regel: Benutzen Sie geprüfte Bibliotheken und Standards, und behandeln Sie Schlüsselverwaltung als erstklassiges System-Requirement.