Sinon si la base58<->bytes gêne trop on peut aussi inventer un autre format, par exemple calculer un nombre de 3 chiffres en base58 à partir du hash brut (modulo ou xor tout simplement).
En faisant le ménage avec vit dans DuniterPy, on a découvert la classe CRCPubkey. Elle s’occupe de gérer la somme de contrôle implémenté par Tortue dans Silkaj et par Inso dans DuniterPy.
En lisant en diagonale l’article, je ne vois pas trop de similarité entre l’algorithme implémenté par Tortue et Inso et celui dans l’article.
Du coup, je ne sais pas si c’est une bonne idée de changer le comportement en changeant un quelque chose d’établi et potentiellement affaiblissant l’algorithme en n’utilisant qu’une seule passe de hashage sha256.
À creuser…
D’après ceci, la double passe sert à éviter une attaque qui utilise la connaissance de la longueur du message pour calculer le hash du message inconnu concaténé à un message connu.
La checksum étant toujours accompagnée de la clé publique et n’étant pas un hash entier, cette attaque n’aurait aucun intérêt. Mais si on veut vraiment l’éviter, il y a SHA512 ou SHA512/256.
Mais elle n’aurait aucun intérêt par rapport aux collisions. Peut-être même que ça augmente le risque de collision : si chaque message a une probabilité P d’avoir une collision lors d’un hash, alors j’imagine qu’avec N hashes, la proba devient P^N.
1 Like