Comment obtenir une adresse .onion spécifique pour votre service caché?
Les adresses .onion doivent normalement être constituées d'une chaîne base32 des 80 premiers bits du hachage SHA1 de la clé privée du serveur (voir spécification d'adresse .ion ).
Aujourd'hui, je suis tombé sur un service qui n'a clairement pas d'adresse arbitraire: http://sms4tor3vcr2geip.onion/
Comment cela fonctionne-t-il et est-il sécurisé?
Shallot est un programme plus ancien, de nouvelles alternatives sont disponibles maintenant:
Scallion - utilise le hachage GPU, a besoin de .NET ou Mono: http://github.com/lachesis/scallion
Eschalot - utilise la recherche par liste de mots, nécessite Unix ou Linux: http://blacksunhq56imku.onion
Eschalot peut trouver des noms plus lisibles par l'homme tels que seedneedgoldcf6m.onion, hostbathdarkviph.onion, etc.
Le tableau des performances cité ci-dessus est un peu obsolète maintenant, les oignons de 8 à 10 caractères sont assez faciles à trouver.
Il y a eu une discussion à l'époque, lorsque l'échalote a fait surface pour la première fois, pour savoir si les noms personnalisés pour les services cachés sont mauvais ou non.
Problème numéro un: les clés générées ont un exposant public beaucoup plus grand que les clés standard produites par TOR, ce qui met une charge un peu plus élevée sur les relais TOR.
Réponse: il a été conclu que la différence est négligeable par rapport aux autres tâches de chiffrement que les relais effectuent en permanence. Dans eschalot, le plus grand exposant public est limité à 4294967295 (4 octets).
Problème numéro deux: Les développeurs TOR peuvent décider de filtrer et de bloquer tous les noms personnalisés.
Réponse: oui, ils le peuvent, mais ils ne l'ont pas encore fait et il n'y a vraiment aucune raison pour eux de le faire. Ils peuvent tout aussi facilement changer la norme pour les noms aléatoires et provoquer le chaos et l'exode de masse sur le réseau.
Problème numéro trois: les noms générés sont facilement usurpés, car le visiteur qui clique sur un lien quelque part peut être trompé par le préfixe .onion apparemment correct sans vérifier le tout. Pour démontrer, lequel est le vrai SilkRoad?
silkroada7bc3kld.onion
silkroadqksl72eb.onion
silkroadcqgi4von.onion
silkroady3c2vzwt.onion
silkroadf3drdfun.onion
silkroadbdcmw7rj.onion
Réponse: non plus, je les ai tous générés pour démontrer le problème. Si vous avez reconnu que ce n'étaient que des faux, vous passez probablement plus de temps sur le SilkRoad que je ne veux en savoir :).
Pour être juste, des adresses complètement aléatoires sont encore pires - si quelqu'un modifie l'un des wikis de liens oignon et remplace une adresse aléatoire par une autre, le visiteur occasionnel utilisant ce wiki ne connaîtra pas la différence.
Solution: c'est essentiellement à la personne de faire attention au site qu'il visite vraiment, mais le propriétaire du site peut créer une adresse lisible par l'homme qui est plus facile à retenir, même s'il s'agit d'un charabia complètement aléatoire. Tant qu'il est long et facile à mémoriser et à identifier. Quelques exemples:
fledarmyusertvmu.onion
wifefeelkillwovk.onion
ladyfirehikehs66.onion
woodcubabitenem2.onion
Je n'ai pas passé le temps à générer intentionnellement de bons noms, j'en ai juste choisi quelques-uns dans la liste que j'avais laissée après avoir testé eschalot. Avec une (très) grande liste de mots, les noms uniques sont faciles à générer, mais il faudra du temps pour parcourir les résultats et localiser manuellement ceux qui sont décents.
Eh bien, c'était mon opinion et cela pourrait être faux.
- Hiro
Vous pouvez utiliser la force brute pour trouver une clé qui correspond en partie au hachage souhaité. Un outil pour cela est Shallot . Le readme de Shallot dit ceci à propos de la sécurité:
On prétend parfois que les clés privées générées par Shallot sont moins sécurisées que celles générées par Tor. C'est faux. Bien que Shallot génère une paire de clés avec un exposant public anormalement grand e, il effectue tous les contrôles d'intégrité spécifiés par PKCS # 1 v2.1 (directement dans sane_key), puis effectue tous les contrôles d'intégrité que Tor fait lorsqu'il génère un RSA paire de clés (en appelant la fonction OpenSSL RSA_check_key).
Pour avoir une idée du temps nécessaire à la génération avec Shallot, également à partir du fichier Lisezmoi:
Il est temps de générer un .onion avec un nombre donné de caractères initiaux sur un processeur de 1,5 GHz:
personnages | temps pour générer (environ) --------------------------------------------- ---------------------- 1 | moins d'une seconde 2 | moins d'une seconde 3 | moins d'une seconde 4 | 2 secondes 5 | 1 minute 6 | 30 minutes 7 | 1 jour 8 | 25 jours 9 | 2,5 ans 10 | 40 ans 11 | 640 ans 12 | 10 millénaires 13 | 160 millénaires 14 | 2,6 millions d'années
Ajout à la réponse de Johan Nilsson (car je ne peux pas poster de commentaires): Il semble que même des URL .onion nommées à 13 caractères ont été créées, un commentaire sur cette entrée du blog Tor mentionne un oignon à 13 caractères URL: deeproadworksbwj.onion (ne vous y connectez pas, je ne sais pas ce que c'est ou si c'est bon).
Je suppose qu'ils forcent simplement la génération de clé privée par force brute, en rejetant ceux qui n'ont pas les propriétés souhaitées.
Puisqu'il n'y a que 7 caractères au début que je suppose qu'ils voulaient, cela ne peut pas être trop coûteux en calcul?
Ces liens pour eschalot sont à jour à ce poste:
Le lien d'origine semble mort (comme l'a également confirmé la deuxième source eschalot). Si vous préférez faire la recherche vous-même:
- http://msydqstlz2kzerdg.onion/search/?q=eschalot (wiki caché), ou
- https://ahmia.fi/search/?q=eschalot (web peu profond)