Si on exclut le problème des leading 1, la forme courte peut représenter 58^11 combinaisons possibles. Soit environ 10^19 combinaisons.
En considérant que je génère un trousseau avec une seed aléatoire directement (donc sans passer par script), j’arrive à générer 1000 trousseaux en 15ms en moyenne (stats réalisées sur gros échantillonnage avec criterion).
Il me faudrait donc environ 4 millions d’années pour générer une collision parfaite.
Sachant que mon vanity n’est pas optimisé je viens de le codé à l’arrache en moins d’une heure, et que l’on peut réussir une attaque phishing avec une collision imparfaite, par exemple 9 caractères sur 11 de conforme dont les 3 du cheksum, mais 11 caractères semble un affichage suffisant pour rendre le phishing très difficile et les collisions involontaire totalement improbables
Concernant la RFC je viens de la review et pour moi tout est ok, sauf sur la longueur minimale de la représentation en base 58 qui doit être d’au moins 43 caractère en attendant DUBPv13 mais c’est un détail
changement de l’utilisation de la forme courte : elle pourra être utilisée dans un champs de recherche, mais pas comme indication directe d’une clef publique.
Je débarque après la bataille :
Qu’est ce qui à amené au choix de xxxx…xxxx:yyy ?
plutôt que bien plus simple à mémoriser pour moi : xxx…xxx:yyy ?
J’ai conscience que le premier est plus difficile à reproduire pour du phishing, mais avez vous calculé si le 2nd est trop peu robuste ?
Ca a été calculé très précisément, à une vache près.
Les 4+4 = 8 caractères viennent du fait que le format court proposé actuellement dans Cesium (et repris dans Silkaj) est de 8 caractères (les 8 premiers).
Non. L’entropie de ce format a été calculée par @elois, qui flotte à coté de toi
Ok, du coup, si c’est parce qu’historiquement on affiche les 8 premiers, on garderais le même degré de sécurité en affichant :
xxx…xxx:yy
et les … et : facilite le découpage mental et donc facilite la mémorisation.
Pourquoi complexifier en rajoutant 3 caractères à retenir en élevant le tout à 11 caractères ?
Personnellement je serais très favorable à descendre le format court au moins à :
xxx…xxx:yyy (entropie : 58^9 = 7.4e15)
voir à : xxx…xxx:yy (entropie : 58^8 = 1.2e14)
plutôt que l’actuel :
xxxx…xxxx:yyy (entropie : 58^11 = 2.4e19)
Je viens de proposer un brouillon pour la nouvelle version de la RFC. J’y ai ajouté :
la possibilité d’accepter les checksums tels que définis par Tortue pour la compatibilité,
la gestion des clefs publiques trop longues,
le fait de n’utiliser qu’une passe de sha256. (l’argument de @1000i100 m’a convaincu : si ça change, autant que ça change pour tout le monde.)
En revanche, je ne suis pas du tout convaincu par la forme courte 3…3:3. J’ai donc conservé la forme 4…4:3 définie précédemment.
Notez que la MR est en brouillon justement pour qu’on parle de ça ping @poka@kimamila@vit@moul@tuxmain si vous voulez en parler.
Ca, c’est un calcul:
pour un PC particulier haut de gamme actuel
pour attaquer une seule clef pub
Un.e attaquant.e qui veut faire perdre confiance dans le réseau Ğ1 peut chercher des collisions parmi toutes les pubkeys membres voire toutes les pubkeys provisionnées. Les usager.e.s ont actuellement la pratique de rechercher les destinataires par l’intermédiaire de Cesium. Je trouve cette fonctionnalité très pratique, et je trouverais encore plus pratique qu’on puisse le faire pour toutes les clefs publiques provisionnees. Mais ceci implique qu’il soit compliqué de trouver des collisions aussi “facilement”.
S’il est possible de trouver une collision pour une clef pub en une semaine, on peut trouver 1000 collisions (1/3 des membres actuels) en trois jours. Et si on peut tromper 1000 fois une personne… Non, attends, c’est pas ça.
Question sur la forme : dois-je créer un nouveau numéro de RFC et passer la version précédente (0016) en “Discontinued” ?
