%20verwenden%2C%20anstatt%20den%20symmetrischen%20Sitzungsschl%C3%BCssel%20mit%20dem%20%C3%B6ffentlichen%20Schl%C3%BCssel%20des%20Servers%20oder%20Clients%20zu%20verschl%C3%BCsseln%3F.png)
Wenn der Client den symmetrischen Sitzungsschlüssel generiert und ihn dann mit dem öffentlichen Schlüssel des Servers verschlüsselt und an den Server sendet, kann nur der Server den verschlüsselten Sitzungsschlüssel mit seinem privaten Schlüssel entschlüsseln und umgekehrt.
Antwort1
Solche Methoden zum Schlüsselaustausch gibt es tatsächlich – und lange Zeit war dies dieprimärArt und Weise, wie Schlüssel in SSL/TLS ausgetauscht wurden, und ein ähnliches Schema war die einzige verfügbare Austauschmethode innerhalb von SSHv1 (das mittlerweile veraltet ist).
Allerdings sind beide Systeme migriertausverschlüsselungsbasierter Schlüsselaustausch zu DH.
Der von Ihnen beschriebene Mechanismus hat ein großes Problem: Wenn der private Schlüssel des Servers gestohlen wird, kann er zum Entschlüsseln verwendet werdenjede einzelne Verbindungdie zuvor mit diesem Schlüsselpaar gemacht wurden oder jemals gemacht werden. (Mit anderen Worten, esfehltGeheimhaltung vorwärts.)
Wenn man bedenkt, dass HTTPS-Zertifikate früher für 5 oder sogar 10 Jahre ausgestellt wurden und SSHverlässt sichWenn die Hostschlüssel nach ihrer Erstellung nicht geändert werden, kann dies ein ziemliches Risiko darstellen. (Zum Beispiel, wenn derselbe Angreifer den Netzwerkverkehr im Rechenzentrum überwacht hat ... oder wenn Sie in einem Land leben, das an Überwachungsprogrammen wie PRISM oder XKeyscore teilgenommen hat.)
(SSHv1 versuchte, dies durch die Generierung flüchtiger RSA-Schlüssel für den Schlüsselaustausch zu mildern, was jedoch den Vorteil eines „bekannten“ Serverschlüssels zum Verschlüsseln komplett zunichtemacht. Und da die Generierung von RSA-Schlüsseln einen erheblichen Verarbeitungsaufwand erfordert, wurde sie nur alle paar Stunden durchgeführt und die flüchtigen Schlüssel waren auf 768 Bit begrenzt.)
Das andere Problem ist, dass die erforderliche Verschlüsselungsfähigkeitbegrenzt Ihre Wahl des Schlüsselalgorithmus. Wenn ich das richtig verstehe, sind asymmetrische digitale Signaturen (zur Authentifizierung des DH-Schlüsselaustauschs) einfacher zu implementieren als asymmetrische Verschlüsselung, selbst für Algorithmen, diekönntebeides tun – und nicht alle können das.
Beispielsweise können EC-Schlüssel nicht direkt zur Verschlüsselung verwendet werden, sondern nur zum Signieren und zum Austauschen von Schlüsseln. Es gibt Verfahren, die die Verschlüsselung mit EC-Schlüsseln implementieren (z. B. ECMQV), aber sie sind eigentlichbasierend auf ECDH-Schlüsselaustausch.Dann könnte man genauso gut einfach DH verwenden.