Convertisseur Base32 / Base58

Ce sont deux réponses à une même question : un canal qui transporte du texte doit transporter des octets. Le Base32 et le Base58 ne sont ni du chiffrement ni du hachage : ils ne cachent rien et ne raccourcissent rien. Ils réécrivent une suite d’octets à l’aide d’un ensemble fixe de caractères lisibles, et quiconque connaît l’ensemble utilisé peut revenir directement à l’original. La seule raison de préférer l’un à l’autre tient à ce que fait le destinataire avec les caractères.

Deux familles effectuent cette réécriture de façons radicalement différentes, et cette différence explique presque toutes les surprises de cette page :

• Empaquetage par bits — Base32, Base32 Hex, Crockford Base32, z-base-32. Les octets sont découpés en groupes fixes, et chaque série de cinq bits devient un caractère. La longueur de la sortie est prévisible à partir de celle de l’entrée ; le dernier groupe, partiellement rempli, est soit complété par des caractères de remplissage, soit laissé court.
• Conversion en grand nombre — toutes les tables Base58. La suite complète d’octets est lue comme un seul énorme nombre en base 256, puis réécrite en base 58. Il n’y a ni groupes ni remplissage ; la longueur ne se divise par rien, et chaque octet nul de tête devient un symbole zéro de tête.

Chaque alphabet est imprimé en entier plutôt que décrit, car deux outils qui impriment des caractères différents sous le même nom ne s’accorderont jamais, quelle que soit l’étiquette. Les lignes RFC 4648 sont normatives ; les lignes Crockford et z-base-32 suivent ce que l’auteur du format a publié ; les trois lignes Base58 sont des conventions répandues et non des normes, c’est pourquoi elles sont listées à part.

L’alphabet écarte I, L, O et U afin qu’aucun symbole ne puisse être lu comme un autre. Ce qui reste ne fait pas la différence entre majuscules et minuscules à la lecture : i et l se lisent comme le chiffre 1, o se lit comme le chiffre 0, et les tirets ne servent qu’à rendre une longue chaîne plus lisible. Par-dessus, le format définit un symbole de contrôle facultatif, qui est la valeur de la chaîne de symboles lue comme un nombre en base 32, prise modulo 37, et écrite avec cinq symboles supplémentaires pour les valeurs 32 à 36.

Le symbole de contrôle est calculé sur la chaîne de symboles, et non sur les octets : comme l’encodeur complète à zéro le dernier groupe, décoder les mêmes caractères revient toujours à la même valeur. C’est pourquoi la valeur de contrôle du tableau peut être reproduite à la main à partir de la seule colonne encodée. Les cinq symboles supplémentaires sont *, ~, $, = et U, pour les valeurs 32, 33, 34, 35 et 36 ; un symbole de contrôle n’est donc pas toujours un chiffre ou une lettre.

Le z-base-32 conserve l’empaquetage par groupes de cinq bits de la RFC 4648 Base32, et ne change que l’ordre des trente-deux caractères. Cet ordre est choisi pour que les caractères qu’une personne est la plus susceptible d’écrire à la main soient les plus faciles à tracer et les moins faciles à confondre. Il n’a pas de remplissage : le lecteur doit donc savoir combien de symboles une valeur doit en comporter ; c’est le prix d’un format conçu pour être lu à la main d’abord.

Le Base58 seul ne permet pas de distinguer une chaîne mal saisie d’une chaîne correcte, car presque toute combinaison de ses cinquante-huit caractères est un nombre valide. Le Base58Check résout ce problème en plaçant les données dans une enveloppe : un octet de version, puis la charge utile, puis les quatre premiers octets du SHA-256 appliqué deux fois de suite aux deux premières parties. Un programme récepteur recalcule ces quatre octets et refuse la chaîne s’ils ne correspondent pas. L’octet de version indique au portefeuille s’il a affaire à une adresse de paiement, à une adresse de script ou à une clé privée.

Le générateur sous le convertisseur prend l’octet de version et la charge utile en hexadécimal, puis écrit la chaîne Base58Check ; le vérificateur relit une chaîne, sépare les quatre octets de somme de contrôle, les recalcule et indique à la fois celle qu’il a trouvée et celle qu’il attendait. Une somme de contrôle erronée signifie ici que la chaîne a été mal saisie ou altérée : cela ne signifie jamais que la charge utile est fausse, car elle n’est jamais interprétée.

• « Le Base64 est du chiffrement. » Non. Il n’y a ni clé ni secret ; n’importe qui peut inverser la sortie. Le Base32 et le Base58 sont dans la même situation, et faire passer une valeur par les trois ne lui ajoute aucune protection.
• « Une chaîne Base58 est une adresse Bitcoin. » Seulement si elle passe aussi la somme de contrôle Base58Check et porte un octet de version reconnu par le logiciel destinataire. Des chaînes Base58 apparaissent dans bien d’autres contextes, y compris des identifiants simples sans aucune somme de contrôle.
• « Les trois alphabets Base58 sont interchangeables. » Ils utilisent les mêmes cinquante-huit caractères dans trois ordres différents ; les mêmes octets produisent donc trois chaînes différentes. Un outil doit savoir lequel employer, et cette page indique toujours celui qu’elle a utilisé.
• « Le remplissage fait partie de la valeur. » Les caractères = ne marquent que le dernier groupe. Deux chaînes Base32 qui ne diffèrent que par leur remplissage décrivent les mêmes octets ; c’est pourquoi le décodeur accepte une chaîne dont le remplissage a été retiré.
• « N’importe quels caractères conviennent. » Chaque alphabet est un ensemble fixe. Un caractère qui n’en fait pas partie n’a pas de valeur : le décodeur s’arrête et indique le caractère ainsi que sa position, au lieu de deviner.

Pourquoi le Base32 utilise-t-il 2-7 et non 0-9 ? Parce que la RFC 4648 a choisi l’alphabet pour qu’il reste dans les caractères admis dans un nom de domaine, et pour qu’il soit facile à lire à voix haute. Le Base32 Hex utilise 0-9 A-V lorsque le tri naturel importe davantage.

Pourquoi une chaîne Base58 commence-t-elle si souvent par 1 ? Chaque octet nul de tête de l’entrée devient un 1 de tête (le premier caractère des alphabets Bitcoin et Flickr). Un octet de version 0x00 est un octet nul, si bien que la plupart des adresses Bitcoin du réseau principal commencent par exactement un 1.

Que charge le bouton Exemple ? L’exemple propre au schéma et au sens affichés à l’écran, jamais un texte fixe. L’encodeur reçoit le texte de l’exemple du schéma lui-même — les vecteurs de la section 10 de la RFC 4648 pour le Base32 et le Base32 Hex, le 12345 de Crockford, les lignes z-base-32 affichées plus haut — et le décodeur reçoit la chaîne encodée de l’alphabet choisi, ce qui rend l’exemple utilisable dans les deux sens. Les trois lignes Base58 portent volontairement le même texte, afin qu’en changeant de schéma et en recliquant sur Exemple on voie côte à côte les trois ordres des mêmes cinquante-huit caractères. Avec le symbole de contrôle Crockford coché, le décodeur reçoit la valeur avec le symbole en fin de chaîne : c’est la seule façon de voir le vérificateur en accepter un.

Cette page envoie-t-elle mes données quelque part ? Non. Toutes les conversions ont lieu dans cet onglet du navigateur, et la page ne contient aucun appel réseau. C’est aussi pourquoi elle fonctionne lorsque le fichier est ouvert directement depuis le disque.

Lequel utiliser pour un secret ? Les secrets des applications d’authentification TOTP et HOTP sont en général du Base32 dans l’alphabet de la RFC 4648, car le secret doit être saisi à la main. Utilisez celui que demande votre logiciel destinataire, et ne comptez jamais sur l’encodage lui-même pour la confidentialité.