Zum Inhalt
Bytearium

Keine Werbung und keine Partnerlinks aktiv

IT-Grundlagen

Public-Key-Verfahren

Public-Key-Verfahren erklärt: öffentlicher und privater Schlüssel, Signieren und Schlüsseltausch, und wie SSH, TLS, WireGuard und Passkeys sie nutzen.

Dieser Eintrag liegt noch unter unserer Mindestlatte für den Suchindex (Umfang und Zahl der Quellen) und wird überarbeitet. Er ist deshalb nicht in Suchmaschinen gelistet.

Deinen öffentlichen Schlüssel verteilst du so freizügig wie deine Mailadresse, und nichts passiert. Den privaten Schlüssel dagegen gibst du niemandem – auch keinem sehr freundlichen Support-Chat.

Kurz gesagt

Ein Public-Key-Verfahren arbeitet mit zwei zusammengehörigen Schlüsseln: einem öffentlichen, den du weitergeben kannst, und einem privaten, den du geheim hältst. Aus dem öffentlichen Schlüssel lässt sich der private praktisch nicht berechnen [1]. Wofür ist welcher Schlüssel da? Was du mit dem privaten Schlüssel signierst, kann jeder mit dem öffentlichen prüfen, und mit deinem öffentlichen Schlüssel können andere Daten schützen oder ein gemeinsames Geheimnis vereinbaren, das nur du als Besitzer des privaten Schlüssels nutzen kannst [1]. SSH, TLS, WireGuard und Passkeys bauen darauf auf. Unsere Einschätzung: Die Mathematik brauchst du selten, aber du musst immer wissen, welcher deiner Schlüssel privat ist und wo er liegt.

So funktioniert’s

  1. Das Schlüsselpaar. Das NIST beschreibt Public-Key-Kryptografie als Verfahren mit zwei zusammengehörigen Schlüsseln, einem zum Verschlüsseln oder Signieren und einem zum Entschlüsseln oder Prüfen [1]. Der private Schlüssel bleibt geheim, der öffentliche darf frei verteilt werden [1].
  2. Signieren. Du signierst Daten mit deinem privaten Schlüssel, und jeder kann die Signatur mit dem passenden öffentlichen Schlüssel prüfen [1]. Ed25519, ein Signaturverfahren aus RFC 8032, arbeitet mit öffentlichen Schlüsseln von 32 Byte und Signaturen von 64 Byte [2].
  3. Einen Schlüssel vereinbaren. Mit Public-Key-Verfahren können zwei Seiten sicher kommunizieren, ohne vorher ein gemeinsames Geheimnis zu teilen [1]. TLS 1.3 macht das mit (EC)DHE, also Diffie-Hellman über endlichen Körpern oder elliptischen Kurven, und der Server weist sich mit einer Signatur über den gesamten Handshake aus, erzeugt mit dem privaten Schlüssel zum öffentlichen Schlüssel in seinem Zertifikat [3].
  4. SSH. SSH-Anmeldungen folgen demselben Muster: Der Server kennt deinen öffentlichen Schlüssel, und dein Client beweist, dass er den passenden privaten besitzt. Seit Version 9.5 erzeugt ssh-keygen von OpenSSH standardmäßig Ed25519-Schlüssel und begründet das mit deren kleinen öffentlichen Schlüsseln [4].
  5. WireGuard. Jede WireGuard-Schnittstelle hat einen privaten Schlüssel und eine Liste von Gegenstellen, und jede Gegenstelle wird über ihren öffentlichen Schlüssel erkannt; eine Verbindung entsteht durch den Austausch öffentlicher Schlüssel, genau wie bei SSH-Schlüsseln [5]. Zu den kryptografischen Bausteinen von WireGuard gehört Curve25519 [5].
  6. Passkeys. Passkeys übertragen dieselbe Idee auf die Anmeldung bei Websites; unser Lexikoneintrag zu Passkeys erklärt, wie.
  7. Wem gehört der Schlüssel? Ein öffentlicher Schlüssel nützt nur, wenn du weißt, wem er gehört. Bei TLS verknüpft das Zertifikat den öffentlichen Schlüssel mit einem Namen [3]; bei SSH und WireGuard prüfst du das selbst, wenn du einen Schlüssel einträgst.

Ein Praxisbeispiel

Du erzeugst auf deinem Laptop ein SSH-Schlüsselpaar:

ssh-keygen -t ed25519

Der Befehl schreibt eine Datei mit dem privaten Schlüssel und eine passende mit dem öffentlichen, deren Name auf .pub endet. Nur die .pub-Datei kommt auf den Server, üblicherweise in ~/.ssh/authorized_keys; der private Schlüssel verlässt deinen Laptop nie. Ab OpenSSH 9.5 ist Ed25519 ohnehin Standard, -t ed25519 macht das nur ausdrücklich [4]. WireGuard folgt demselben Muster: Du gibst deiner Gegenstelle die Zeile mit deinem PublicKey und behältst den PrivateKey für dich [5]. Das ist ein allgemeiner Ablauf und keine Kopie unserer Serverkonfiguration.

Prüfliste

  • Schütze jeden privaten Schlüssel mit einer Passphrase oder einem Hardware-Schlüssel und schick ihn nie an jemanden.
  • Gib nur öffentliche Schlüssel weiter: die .pub-Datei bei SSH, den PublicKey-Wert bei WireGuard [5].
  • Nimm für neue SSH-Schlüssel Ed25519; OpenSSH nutzt es seit Version 9.5 standardmäßig [4].
  • Prüfe, ob ein öffentlicher Schlüssel wirklich zur Gegenseite gehört, bevor du ihm vertraust [3].
  • Ersetze ein Schlüsselpaar sofort, wenn ein privater Schlüssel abhandengekommen sein könnte.

Primärquellen

Diese Quellen sind die Grundlage der Seite. Das heißt nicht, dass jede Aussage einzeln nachgeprüft wurde; ob ein Prüfbeleg vorliegt, steht oben unter „Stand“. Einordnung und Prüfliste sind unsere eigene Arbeit.

Für diese Fassung liegt noch kein dokumentierter Prüfbeleg vor. Der Text stützt sich auf die genannten Quellen.

Entstehung: Bytearium erstellt diese Seiten mit Unterstützung von KI und verantwortet die Veröffentlichung. KI kann sich irren, deshalb nennen wir Quellen und Prüfstand offen.

  1. NIST CSRCPublic key cryptography
  2. IETFRFC 8032: Edwards-Curve Digital Signature Algorithm (EdDSA)
  3. IETFRFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3
  4. OpenSSHAnnounce: OpenSSH 9.5 released
  5. WireGuardWireGuard: fast, modern, secure VPN tunnel

Auf dieser Seite gibt es keine Werbung und keine Partnerlinks.