Anatomie van een v3-onion-adres: wat de 56 tekens werkelijk coderen
Elk v3-onion-adres lijkt op toetsenbordruis: 56 kleine letters en cijfers, eindigend op de letter d. Dat laatste teken is geen toeval, en niets anders in de reeks is dat ook. Elk van de 56 tekens is berekend volgens een kort recept uit de rendezvous-specificatie van Tor, die de openbare sleutel van een service omzet in precies het adres dat een Tor Browser accepteert.
Wat de 56 tekens werkelijk coderen
De coderingssectie van de rendezvous-specificatie definieert een onion-adres als de base32-codering van precies 35 bytes, gevolgd door het achtervoegsel .onion:- Bytes 1-32: de openbare ed25519-identiteitssleutel van de service - de sleutel waarvan de privéhelft alles ondertekent wat de service publiceert.
- Bytes 33-34: een checksum, genomen als de eerste twee bytes van SHA3-256 over de constante tekenreeks ".onion checksum", de openbare sleutel en de versiebyte.
- Byte 35: een versieveld, vastgesteld op 0x03 voor adressen van de derde generatie.
De checksum die typefouten onderschept
De twee checksum-bytes bestaan omdat onion-namen geen register, geen WHOIS en geen automatisch aanvullen van de browser hebben die een fout onderschept. Het ontwerp leent een idee van Bitcoin, waarvan de Base58Check-adressen een vergelijkbaar, op een hash gebaseerd achtervoegsel toevoegen; toen Tors ontwikkelaars het formaat in begin 2017 voorstelden, zetten ze de rekenkunde uiteen in een voorstel op de mailinglijst:"In geval van een typefout in een adres is er een kans van 1/65536 dat we de fout niet detecteren."Eén verkeerd getypt teken verandert de hash-invoer, waardoor de herberekende checksum bijna nooit klopt en de Tor-client de reeks als ongeldig verwerpt voordat er een verbinding wordt geprobeerd. Slechts ongeveer één op de 65.536 fouten glipt erdoorheen, en een typefout die de checksum overleeft belandt op een willekeurige 32-bytesleutel die vrijwel zeker bij geen enkele service hoort. De prijs van dat restantrisico is twee bytes; het alternatief zou zijn stil te verbinden met waar een verkeerd getypt adres ook naar decodeert.
Het adres is de sleutel: geen certificaatautoriteit nodig
Op het gewone web vertrouwt een browser erop dat een naam bij een sleutel hoort, omdat een certificaatautoriteit dat zegt. Onion-adressen verplaatsen die garantie naar de naam zelf. De 56 tekens zijn de openbare sleutel van de service, dus het adres heeft geen register nodig en kan niet twee keer worden uitgegeven - twee services kunnen er één niet delen, want elk adres is een andere sleutel. De onion-service-documentatie van Tor beschrijft hoe dit werkt bij het verbinden: de service publiceert een descriptor die is ondertekend met de privéhelft van de sleutel die in zijn adres is gecodeerd, en de client verifieert die handtekening nog voordat er een circuit wordt gebouwd, waarmee wordt bevestigd dat de descriptor "alleen door die ene onion-service en niemand anders geproduceerd kan zijn". Dit is wat Tors ontwikkelaars bedoelen met zelfauthenticatie. Het overzicht van 2021 van het Tor Project over v3-services schrijft ook de privacywinst van het formaat toe aan hetzelfde ontwerp: directory-relays werken alleen met een geblindeerde afgeleide van de identiteitssleutel, zodat introductiepunten nooit de openbare sleutel te zien krijgen die het adres spellt. Authenticatie wordt dus niet via derden toegevoegd; die zit in elk teken.Wat een gelekte privésleutel betekent
Identiteit in één sleutel bundelen, betekent risico in één bestand bundelen. Wie de privésleutel van een service bemachtigt, kan geldige descriptors ondertekenen, introducties beantwoorden en de service volledig imiteren - en niets aan het adres zal verdacht lijken, want de aanvaller gebruikt de echte sleutel. De checksum gaat gewoon door, de handtekening verifieert gewoon; de imitatie is onzichtbaar voor elke controle aan clientzijde die het formaat biedt."Als uw sleutels lekken, kunnen anderen uw onion-service imiteren, waardoor die als gecompromitteerd, nutteloos en gevaarlijk om te bezoeken geldt."Anders dan bij een gecompromitteerd wachtwoord is er niets te roteren: het adres kan niet veranderen zonder het op te geven. De installatiegids van Tor behandelt het bestand private_key als het enige geheim dat telt, waarschuwt operators het privé te houden en raadt een veilige back-up aan als de service zijn hardware moet overleven. Voor wie onion-services van buitenaf volgt, is de praktische les dat een structureel perfect adres alleen bewijst dat de reeks intact is - het zegt niets over wie de sleutels vandaag in handen heeft.
Een checksum met de hand controleren
De hele verificatie past in een paar regels van elke scripttaal met SHA-3, en de stappen volgen rechtstreeks uit de specificatie:- Verwijder het achtervoegsel .onion en controleer of er 56 base32-tekens overblijven.
- Decodeer ze naar 35 bytes: de eerste 32 zijn de openbare sleutel, de volgende twee zijn de checksum en de laatste is de versiebyte.
- Voer SHA3-256 de constante tekenreeks ".onion checksum" toe, daarna de 32 sleutel-bytes, daarna de versiebyte.
- Vergelijk de eerste twee bytes van de digest met de checksum-bytes. Een overeenkomst betekent dat de reeks correct is gekopieerd.