@tuxmain je préfère attendre qu’il y ai une spec commune qui fasse consensus
Il y a peut-être plusieurs implémentations, mais le format et la somme de contrôle sont les mêmes :
<pubkey>:<checksum>
Je pense qu’il y a consensus sur ce format de somme de contrôle de la clé publique.
À quoi fais-tu référence Éloïs ?
D’ailleurs, pourquoi deux passes de SHA256 ? C’est mieux qu’une seule ?
à la discussion précise de ce sujet
Kimamila propose que, après décodage de la clef pub, on vérifie qu’elle fasse bien 32 octets avant de calculer le checksum. Si ce n’était pas le cas, on ajouterait des octets nuls en début de pubkey. Avec cette spec, les deux clefs pub indiquées ci-avant auraient le même checksum, 8pQ
.
Je suis tout à fait d’accord avec cette spec, reste qu’à la rédiger !
Je crois que ça vient de BTC, dont s’est inspiré @Tortue. Mais @elois peut préciser. Je ne sais pas si c’est mieux.
En effet ça viens du BTC et ça ne sert à rien. Un seul SHA256 est satisfaisant.
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
et5Hj6…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.
Oui.
oui
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
RFC implémentée, avec des tests sur les 2 exemples fournis, ça fonctionne nickel
EDIT : Je viens de publier la version 0.46 de dup-crypto qui inclus le support des checksum, cc @tuxmain
J’ai ajouté des petits changements :
- taille de la clef pub {43,44}
- utilisation de MUST et CAN pour être plus clair
- 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
C’est possible que la question soit posée ici pour servir de reminder
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)
Because 3, is a magic number…
Pour moi le checksum est très important et 2 caractères ne riment plus à grand chose, déjà trois c’est pas beaucoup…
Quitte a réduire, je préfère nettement réduire la clef à 3…3:3. On est pas à une vache près, hein…
3…3:3 ça me va