Anatomie einer v3-Onion-Adresse: Was die 56 Zeichen wirklich kodieren
Jede v3-Onion-Adresse sieht aus wie Tastaturrauschen: 56 Kleinbuchstaben und Ziffern, endend auf den Buchstaben d. Dieses letzte Zeichen ist kein Zufall, und nichts anderes an der Zeichenkette ist es auch. Jedes der 56 Zeichen wird nach einem kurzen Rezept aus der Rendezvous-Spezifikation von Tor berechnet, die den öffentlichen Schlüssel eines Dienstes in genau die Adresse umwandelt, die ein Tor Browser akzeptiert.
Was die 56 Zeichen tatsächlich kodieren
Der Kodierungsabschnitt der Rendezvous-Spezifikation definiert eine Onion-Adresse als die Base32-Kodierung von genau 35 Bytes, gefolgt vom Suffix .onion:- Bytes 1-32: der öffentliche ed25519-Identitätsschlüssel des Dienstes - der Schlüssel, dessen private Hälfte alles signiert, was der Dienst veröffentlicht.
- Bytes 33-34: eine Prüfsumme, gebildet aus den ersten zwei Bytes von SHA3-256 über die konstante Zeichenkette ".onion checksum", den öffentlichen Schlüssel und das Versionsbyte.
- Byte 35: ein Versionsfeld, festgelegt auf 0x03 für Adressen der dritten Generation.
Die Prüfsumme, die Tippfehler abfängt
Die zwei Prüfsummen-Bytes existieren, weil Onion-Namen kein Register, kein WHOIS und keine Browser-Autovervollständigung haben, die einen Fehler abfängt. Das Design lehnt sich an Bitcoin an, dessen Base58Check-Adressen ein ähnliches, aus einem Hash abgeleitetes Suffix anhängen; als Tors Entwickler das Format Anfang 2017 vorschlugen, legten sie die Arithmetik in einem Vorschlag auf der Mailingliste dar:"Im Falle eines Tippfehlers in der Adresse haben wir eine Wahrscheinlichkeit von 1/65536, den Fehler nicht zu erkennen."Ein einzelnes vertipptes Zeichen ändert die Hash-Eingabe, sodass die neu berechnete Prüfsumme fast nie passt und der Tor-Client die Zeichenkette als ungültig zurückweist, bevor irgendeine Verbindung versucht wird. Nur etwa einer von 65.536 Fehlern schlüpft durch, und ein Tippfehler, der die Prüfsumme übersteht, landet auf einem zufälligen 32-Byte-Schlüssel, der mit an Sicherheit grenzender Wahrscheinlichkeit zu keinem Dienst gehört. Der Preis für dieses Restrisiko sind zwei Bytes; die Alternative wären stille Verbindungen zu dem, was auch immer eine verunglückte Adresse dekodiert.
Die Adresse ist der Schlüssel: keine Zertifizierungsstelle nötig
Im gewöhnlichen Web vertraut ein Browser darauf, dass ein Name zu einem Schlüssel gehört, weil eine Zertifizierungsstelle das bestätigt. Onion-Adressen verlagern diese Bestätigung in den Namen selbst. Die 56 Zeichen sind der öffentliche Schlüssel des Dienstes, daher braucht die Adresse kein Register und kann nicht doppelt vergeben werden - zwei Dienste können sich keine teilen, weil jede Adresse ein anderer Schlüssel ist. Tors Onion-Service-Dokumentation beschreibt, wie das beim Verbindungsaufbau aussieht: Der Dienst veröffentlicht einen Deskriptor, signiert mit der privaten Hälfte des Schlüssels, der in seiner Adresse kodiert ist, und der Client prüft diese Signatur, bevor er überhaupt einen Circuit aufbaut - und bestätigt damit, dass der Deskriptor "nur von diesem Onion-Service und von niemand sonst erzeugt sein kann". Das meinen Tors Entwickler, wenn sie von Selbstauthentifizierung sprechen. Der Überblick des Tor Projects über v3-Services von 2021 führt auch die Datenschutzgewinne des Formats auf dasselbe Design zurück: Verzeichnis-Relays erhalten nur eine geblindete Ableitung des Identitätsschlüssels, sodass Introduction Points nie den öffentlichen Schlüssel erfahren, den die Adresse buchstabiert. Authentifizierung wird nicht über Dritte ergänzt; sie steckt in jedem einzelnen Zeichen.Was ein geleakter privater Schlüssel bedeutet
Wer die Identität in einem Schlüssel bündelt, bündelt das Risiko in einer Datei. Wer den privaten Schlüssel eines Dienstes besitzt, kann gültige Deskriptoren signieren, Introductions beantworten und den Dienst vollständig imitieren - und nichts an der Adresse wirkt verdächtig, weil der Angreifer den echten Schlüssel verwendet. Die Prüfsumme stimmt, die Signatur ist gültig; die Imitation bleibt für jede clientseitige Prüfung unsichtbar, die das Format bietet."Wenn Ihre Schlüssel abhandenkommen, können andere Ihren Onion-Service imitieren; er gilt dann als kompromittiert, nutzlos und gefährlich zu besuchen."Anders als bei einem kompromittierten Passwort gibt es nichts zu rotieren: Die Adresse lässt sich nicht ändern, ohne sie aufzugeben. Tors Setup-Anleitung behandelt die Datei private_key als das eine Geheimnis, das zählt, warnt Betreiber, sie privat zu halten, und empfiehlt, sie sicher zu sichern, falls der Dienst seine Hardware überleben soll. Für alle, die Onion-Services von außen beobachten, ist die praktische Lektion: Eine strukturell perfekte Adresse beweist nur, dass die Zeichenkette intakt ist - sie sagt nichts darüber, wer die Schlüssel dahinter heute hält.
Eine Prüfsumme von Hand überprüfen
Die gesamte Überprüfung passt in wenige Zeilen einer beliebigen Skriptsprache mit SHA-3, und die Schritte ergeben sich unmittelbar aus der Spezifikation:- Das Suffix .onion entfernen und prüfen, dass 56 Base32-Zeichen übrig bleiben.
- Sie in 35 Bytes dekodieren: die ersten 32 sind der öffentliche Schlüssel, die nächsten zwei sind die Prüfsumme und das letzte ist das Versionsbyte.
- SHA3-256 mit der konstanten Zeichenkette ".onion checksum" füttern, dann mit den 32 Schlüssel-Bytes, dann mit dem Versionsbyte.
- Die ersten zwei Bytes des Digests mit den Prüfsummen-Bytes vergleichen. Eine Übereinstimmung bedeutet, dass die Zeichenkette korrekt übernommen wurde.