Après la discussion de mardi dernier, voici la RFC concernant le format de checksum:
comme convenu :
la double passe de sha256 est conservée. Quoique peu utilisées, des checksums sont déjà dans la nature, et nous préférons conserver la compatibilité avec l’ancien format.
la forme courte d’affichage est définie pour clef pub + checksum
TODO / incertitudes :
la RFC donne la longueur des clefs publiques comprise entre 40 et 44 caractères, conformément à l’implémentation de @elois, et conformément au DUBPv13. Dois-je la définir à {43,44} tant queDUBPv12 est valables ?
la MR vise-t-elle le bon dépôt ?
Remarques concernant la forme courte:
sur des clefs publiques commençant par 1, les formes courtes peuvent être très différentes suivant les librairies. 1111…v2nx:56f et 5Hj6…v2nx:56f peuvent désigner une même clef publique de longueur 40 OU 44 caractères.
la forme courte autorise des collisions entre clefs publiques. Je n’ai pas évalué la probabilité de collision.
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)
