Une clé publique Nostr ressemble aujourd’hui à ce genre de chose : npub180cvv07tjdrrg.... C’est déjà plus humain qu’une soupe hexadécimale, mais personne n’a envie de dicter cinquante-neuf caractères au téléphone.
Le 19 août 2026, Vrypan a publié Sing-song, un brouillon d’encodage qui prend le problème au pied de la lettre : au lieu d’améliorer encore l’alphabet, il transforme les bits en petites syllabes que l’on peut prononcer.1
Une valeur de 256 bits devient alors quelque chose comme :
moji-buba-liku-moru-lizi-wiji-zusi-jilu-…
Ça chante davantage qu’un 9F4A7B…. Mais une question arrive immédiatement : si nous rendons une clé agréable à dire, qu’est-ce qui nous protège quand nous la disons mal ?
Nous avons donc pris l’implémentation de référence publiée dans le brouillon, puis comparé exactement la même valeur 256 bits avec hex, Base58, Proquint, RFC1751 et BIP39.
Six bits
Sing-song possède seize consonnes et quatre voyelles. Une syllabe contient toujours une consonne suivie d’une voyelle : ba, di, fo, gu et ainsi de suite.1
16 × 4 = 64 combinaisons.
Une syllabe transporte donc exactement 6 bits.
L’algorithme lit les données comme un flux binaire, coupe ce flux en paquets de six bits, utilise quatre bits pour choisir la consonne et deux pour choisir la voyelle. Si le dernier paquet est incomplet, les bits manquants sont remplis avec des zéros canoniques.1
Pour L octets, le nombre de syllabes vaut :
ceil(8 × L / 6)
Une clé de 32 octets, donc 256 bits, demande 43 syllabes, soit 86 lettres avant les tirets.
Le choix a une propriété élégante : trois octets font 24 bits, exactement quatre syllabes. À ces frontières, un préfixe de l’encodage correspond exactement au préfixe des octets d’origine.1
Même clé
Nous avons utilisé SHA-256("sing-song"), le même vecteur de test que le brouillon, puis produit six représentations.
Base58 utilise ici 44 caractères. L’hex en utilise 64. Proquint arrive à 80 lettres, réparties en seize groupes CVCVC. Sing-song en demande 86. Notre application de RFC1751 sur quatre blocs de 64 bits produit 24 mots et 90 lettres ; BIP39 donne également 24 mots, mais 131 lettres sur ce vecteur.
Cette dernière comparaison a une limite volontaire : un mot n’est pas une unité de parole constante. EACH et ELEVATOR n’occupent évidemment pas la même durée. Nous comparons donc structure et densité écrite, pas un chronomètre de diction.
Le contraste avec Proquint est particulièrement intéressant. Proquint existe depuis 2009 et encode 16 bits dans un groupe CVCVC à partir de seize consonnes et quatre voyelles.3 Son Internet-Draft IETF le présente comme un identifiant lisible et prononçable, mais cette révision a expiré en avril 2026 : c’est lui aussi un travail de spécification, pas un standard IETF adopté.3
Sing-song préfère des unités plus petites et toujours ouvertes : CV, CV, CV. Il paie davantage de syllabes pour obtenir une grammaire presque triviale.
Grammaire utile
Cette simplicité détecte déjà certaines erreurs.
Une position consonne n’accepte que l’une des seize consonnes autorisées ; une position voyelle n’accepte que a, i, o ou u. Le brouillon autorise également quelques normalisations dépendantes de la position, comme 0 → o, 1 → l ou e → i.1
Sur notre chaîne 256 bits, nous avons remplacé chaque lettre, tour à tour, par chacune des 25 autres lettres de a à z. 64 % de ces substitutions produisent immédiatement une forme invalide grâce à l’alternance consonne/voyelle.
C’est plutôt bon pour deux lignes de parser.
Mais ce résultat cache le cas qui compte le plus.
Bonne mauvaise
Si ba devient pa, la nouvelle syllabe est parfaitement légale.
Sing-song le dit explicitement : il n’intègre ni code correcteur ni checksum. Une syllabe valide remplacée par une autre syllabe valide donne une autre valeur tout aussi valide.1
Nous avons épuisé toutes les substitutions de lettre qui respectent la classe de la position sur notre exemple : autre consonne pour une consonne, autre voyelle pour une voyelle. Cela donne 774 mutations. Résultat : 0 détectée.
Proquint partage le même problème de fond. Ses contraintes CVCVC attrapent les caractères impossibles et les positions absurdes, mais une autre consonne autorisée reste une autre valeur valide.3
RFC1751 a fait un autre compromis dès 1994. Il encode 64 bits avec six mots choisis dans une liste de 2048, donc 66 bits de capacité, et utilise les deux bits restants comme parité.2 Sur les 49 128 substitutions d’un mot valide par un autre que nous avons essayées à travers les quatre blocs de notre valeur 256 bits, 75,04 % sont rejetées.
BIP39 pousse l’idée plus loin : pour 256 bits d’entropie, il ajoute huit bits issus de SHA-256 puis découpe le tout en 24 indices de onze bits.4 Dans le même test exhaustif de 49 128 substitutions d’un mot valide, 99,59 % sont rejetées par le checksum.
Cela ne rend pas BIP39 « meilleur » en toute circonstance. BIP39 sert à transporter une entropie de portefeuille sous forme mnemonic et dépend d’une liste de 2048 mots ; Sing-song veut encoder n’importe quelle chaîne d’octets avec une règle minuscule et générative.14
Ils optimisent des choses différentes.
Le téléphone
Le brouillon part précisément d’une ambition vocale : pouvoir lire la chaîne à quelqu’un et lui faire retaper correctement.1
C’est là que les 64 syllabes deviennent délicates.
ba et pa, da et ta, ga et ka, fa et va, sa et za sont des paires proches. L’auteur le sait : parmi les alternatives étudiées, il décrit un codebook qui fusionnerait plusieurs classes confusables, dont b/p, d/t, g/k, f/v, s/z, m/n et l/r.1
Le système actuel préfère pourtant garder 64 combinaisons régulières plutôt que d’ajouter un gros dictionnaire et des syllabes fermées plus lourdes.
Ce choix est presque l’inverse de la liste PGP. Celle-ci a été construite pour transmettre des octets à la voix et utilise des mots sélectionnés pour leur distance phonétique ; elle alterne même deux listes différentes afin d’aider à repérer transpositions, répétitions et omissions.7
Sing-song mise sur la règle. PGP mise sur le vocabulaire.
Le premier tient dans quelques constantes. Le second a besoin de centaines de mots soigneusement choisis.
Encore brouillon
Il faut aussi lire Sing-song pour ce qu’il est aujourd’hui : draft v0.1.2, pas format installé.1
Le billet contient une implémentation Python complète, mais ne lie pas de dépôt dédié et n’annonce pas de licence logicielle pour ce code. Pour quelqu’un qui voudrait intégrer le format dans un produit, la question des droits de réutilisation mérite donc d’être clarifiée avant de copier l’implémentation.
On voit même une petite couture éditoriale dans la spécification : l’alphabet de voyelles est a i o u, alors que la table de prononciation affiche aussi e; plus loin, e réapparaît comme erreur de transcription éventuellement normalisable vers i.1
Rien de dramatique. C’est exactement le genre de détail qu’un brouillon public sert à faire remonter.
Seize variantes
Sing-song ajoute aussi seize variants : plusieurs chaînes prononçables peuvent représenter les mêmes octets.1
Pour les variantes 1 à 15, un flux SHAKE-256 public est XORé avec les données avant encodage, puis un suffixe de deux lettres indique quelle variante a été utilisée. Le masque est déterministe, réversible et ne prétend fournir aucune confidentialité.1
L’intérêt est esthétique ou ergonomique : si une représentation produit une séquence pénible à dire, l’application peut en choisir une autre tout en restant réversible.
Mais le suffixe de variante n’est toujours pas un checksum. Il indique comment décoder, pas si ce que vous avez entendu était exact.
Nostr court
L’application la plus séduisante du billet concerne Nostr.
NIP-19 représente déjà les clés publiques de 32 octets sous forme npub Bech32 pour l’affichage, le partage et la saisie humaine.5 Bech32 possède six caractères de checksum et son design garantit notamment la détection de toute erreur affectant jusqu’à quatre caractères dans les conditions prévues par le format.6
Vrypan propose autre chose : prendre seulement les huit premières syllabes de Sing-song comme username lisible.1
Huit syllabes × six bits = 48 bits.
Comme la propriété de préfixe est directe, cela revient exactement à encoder les six premiers octets de la clé publique. Ce n’est pas un hash séparé, et le billet insiste sur le fait que ce username n’est pas globalement unique.1
Nous avons calculé la collision anniversaire pour des clés supposées aléatoires.
Avec 1 million de clés, la probabilité d’au moins une collision dans l’ensemble est d’environ 0,18 %. À 10 millions, elle monte à 16,3 %. À 20 millions, 50,9 %. Le seuil théorique de 50 % se situe autour de 19,75 millions.
Ces nombres ne disent pas qu’un utilisateur particulier a une chance sur deux d’être imité. Ils décrivent la probabilité qu’au moins une paire partage le même préfixe dans toute la population.
Surtout, ils confirment le rôle correct de ces huit syllabes : un raccourci de recherche, pas une preuve d’identité. Le billet imagine d’ailleurs le client Nostr décodant les six octets, cherchant les comptes candidats puis laissant l’utilisateur choisir.1
Dire quoi
Sing-song devient plus convaincant lorsque l’on cesse de lui demander de remplacer tous les formats.
Hex reste formidable pour les machines et le debug. Base58 ou Bech32 restent bien plus courts à l’écrit. BIP39 accepte une longue phrase parce qu’il veut transporter une entropie avec checksum. RFC1751 paie un dictionnaire pour avoir des mots courts et un peu de parité. Proquint groupe davantage de bits dans cinq lettres.
Sing-song choisit un autre point du triangle :
pas de dictionnaire, une prononciation régulière, six bits par petite syllabe.
C’est assez simple pour que l’encodage entier se comprenne presque de tête, et assez structuré pour rejeter beaucoup de fautes grossières.
Mais le test révèle également sa frontière nette. La chaîne est plus facile à dire ; elle n’est pas plus sûre parce qu’elle sonne mieux.
Si l’objectif est de vérifier une clé complète à la voix, un checksum reste le morceau manquant. Si l’objectif est de donner à une longue clé un surnom déterministe, décodable et presque chantable, huit syllabes peuvent déjà faire un très joli travail.