Anatomie d'une adresse onion v3 : ce que les 56 caractères encodent réellement
Toute adresse onion v3 ressemble à un bruit de clavier : 56 lettres minuscules et chiffres qui se terminent par la lettre d. Ce dernier caractère n'est pas une coïncidence, et rien d'autre dans la chaîne ne l'est non plus. Chacun des 56 caractères est calculé selon une courte recette de la spécification rendezvous de Tor, qui transforme la clé publique d'un service en exactement l'adresse qu'acceptera un Tor Browser.
Ce que les 56 caractères encodent réellement
La section d'encodage de la spécification rendezvous définit une adresse onion comme l'encodage base32 d'exactement 35 octets, suivis du suffixe .onion :- Octets 1 à 32 : la clé publique d'identité ed25519 du service - la clé dont la moitié privée signe tout ce que le service publie.
- Octets 33 et 34 : une somme de contrôle, constituée des deux premiers octets de SHA3-256 portant sur la chaîne constante ".onion checksum", la clé publique et l'octet de version.
- Octet 35 : un champ de version, fixé à 0x03 pour les adresses de troisième génération.
La somme de contrôle qui attrape les fautes de frappe
Les deux octets de somme de contrôle existent parce que les noms onion n'ont ni registre, ni WHOIS, ni complétion automatique du navigateur pour rattraper une erreur. Le concept est emprunté à Bitcoin, dont les adresses Base58Check ajoutent un suffixe similaire dérivé d'un hachage ; lorsque les développeurs de Tor ont proposé le format début 2017, ils en ont exposé l'arithmétique dans une proposition sur la liste de diffusion :"En cas de faute de frappe dans une adresse, nous avons une probabilité de 1/65536 de ne pas détecter l'erreur."Un seul caractère mal tapé modifie l'entrée du hachage, si bien que la somme recalculée ne correspond presque jamais et que le client Tor rejette la chaîne comme invalide avant toute tentative de connexion. Une erreur sur 65 536 environ passe au travers, et une faute qui survit à la somme de contrôle aboutit à une clé aléatoire de 32 octets qui n'appartient presque certainement à aucun service. Le coût de ce risque résiduel : deux octets ; l'alternative serait des connexions silencieuses vers ce que décode une adresse mal tapée.
L'adresse est la clé : pas besoin d'autorité de certification
Sur le web ordinaire, un navigateur fait confiance à un nom parce qu'une autorité de certification affirme qu'il appartient à une clé. Les adresses onion intègrent cette garantie dans le nom lui-même. Les 56 caractères sont la clé publique du service ; l'adresse n'a donc besoin d'aucun registre et ne peut pas être délivrée deux fois - deux services ne peuvent pas la partager, car chaque adresse est une clé différente. La documentation onion services de Tor décrit ce qui se passe à la connexion : le service publie un descripteur signé avec la moitié privée de la clé encodée dans son adresse, et le client vérifie cette signature avant même de construire un circuit, confirmant que le descripteur "n'a pu être produit que par ce service onion et par personne d'autre". C'est ce que les développeurs de Tor entendent par auto-authentification. Le panorama 2021 du Tor Project sur les services v3 attribue au même concept les gains de confidentialité du format : les relais d'annuaire ne manipulent qu'une dérivation aveuglée de la clé d'identité, si bien que les points d'introduction ne connaissent jamais la clé publique que l'adresse épelle. L'authentification, autrement dit, n'est pas ajoutée par un tiers ; elle est présente dans chaque caractère.Ce que signifie une clé privée divulguée
Concentrer l'identité dans une clé concentre le risque dans un fichier. Quiconque obtient la clé privée d'un service peut signer des descripteurs valides, répondre aux introductions et usurper complètement l'identité du service - et rien dans l'adresse n'y paraîtra, car l'attaquant utilise la clé authentique. La somme de contrôle passe, la signature se vérifie ; l'usurpation est invisible pour toutes les vérifications côté client que le format offre."Si vos clés fuient, d'autres personnes peuvent usurper votre onion service, le rendant compromis, inutile et dangereux à visiter."Contrairement à un mot de passe compromis, il n'y a rien à faire tourner : l'adresse ne peut pas changer sans y renoncer. Le guide de configuration de Tor traite le fichier private_key comme le seul secret qui compte, invite les opérateurs à le garder privé et recommande d'en faire une copie de sécurité si le service doit survivre à son matériel. Pour qui observe les onion services de l'extérieur, la leçon pratique est qu'une adresse structurellement parfaite prouve seulement que la chaîne est intacte - elle ne dit rien sur qui détient aujourd'hui les clés.
Vérifier une somme de contrôle à la main
Toute la vérification tient en quelques lignes de n'importe quel langage de script disposant de SHA-3, et les étapes découlent directement de la spécification :- Retirez le suffixe .onion et confirmez qu'il reste 56 caractères base32.
- Décodez-les en 35 octets : les 32 premiers sont la clé publique, les deux suivants sont la somme de contrôle et le dernier est l'octet de version.
- Donnez à SHA3-256 la chaîne constante ".onion checksum", puis les 32 octets de la clé, puis l'octet de version.
- Comparez les deux premiers octets de l'empreinte aux octets de la somme de contrôle. Une correspondance signifie que la chaîne a été copiée correctement.