# Format de clé et vérification
**URL:** https://forum.duniter.org/t/format-de-cle-et-verification/12574
**Category:** Applications
**Tags:** ss58, base58
**Created:** [16 October 2024 00:19 UTC](https://forum.duniter.org/t/format-de-cle-et-verification/12574 "2024-10-16T00:19:29Z")
**Posts on this page:** 8
**Page:** 1
### Author:  [@Spiranne](https://forum.duniter.org/u/Spiranne)
#### Post date: [16 October 2024 00:19 UTC](https://forum.duniter.org/t/format-de-cle-et-verification/12574/1 "2024-10-16T00:19:29Z")
Bonjour,
je ne sais si je suis sur le bon topic pour cette question si non, merci de bien vouloir m’indiquer le bon endroit.
une question : **au sujet de la “nouvelle forme de clé publique”**
Les gens ont l’habitude (en tout cas on leur conseille) de garder en mémoire au moins les 5 premiers caractères de leur clé publique (actuelle) pour vérifier qu’ils sont bien sur leur compte quand ils se connectent. (et c’est aussi ce que l’on communique à ceux qui nous donnent des G1, pour la même raison)…
J’ai lu quelque part qu’elle resterait visible sur Césium2 : est-ce confirmé ?
Si oui cela devrait permettre la vérification dont je parle,
Si non, cela risque de perturber certains qui fonctionnent avec des comptes créés avant la bascule…
---
### Author:  [@Maaltir](https://forum.duniter.org/u/Maaltir)
#### Post date: [16 October 2024 08:35 UTC](https://forum.duniter.org/t/format-de-cle-et-verification/12574/2 "2024-10-16T08:35:05Z")
Réponse sur le forum utilisateur :
[https://forum.monnaie-libre.fr/t/est-ce-que-mon-pad-repond-a-toutes-les-questions/30656/15](https://forum.monnaie-libre.fr/t/est-ce-que-mon-pad-repond-a-toutes-les-questions/30656/15)
---
### Author:  [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [16 October 2024 09:11 UTC](https://forum.duniter.org/t/format-de-cle-et-verification/12574/3 "2024-10-16T09:11:38Z")
### Quelques bases pour comprendre
Une clé publique sur la [courbe 25519](https://fr.wikipedia.org/wiki/Curve25519) est un nombre compris entre 0 et 79228162514264337593543950335 (8^32-1). Sur un ordinateur, ce nombre est stocké sur 256 bits (0 ou 1), soit 32 octets (groupes de 8 bits).
```auto
# ce nombre en base binaire (256 caractères parmi 2)
1101010000110101100100111100011100010101111111011101001100011100011000010001010000011010101111010000010010101001100111111101011010000010001011001000010101011000100001010100110011001101111000111001101001010110100001001110011110100101011011011010001001111101
# ce nombre en base hexadécimale (64 caractères parmi 16)
d43593c715fdd31c61141abd04a99fd6822c8558854ccde39a5684e7a56da27d
```
Pour représenter ce nombre de manière plus courte, on peut choisir une autre base, la [base 58](https://en.wikipedia.org/wiki/Binary-to-text_encoding#Base58) utilise 58 caractères qui ont l’avantage d’être facile à lire sans ambiguïté.
```auto
# ce nombre en base 58 (44 caractères parmi 58)
FHNpKmJrUtusuvKPGomAygQqeiks98bdV6yD61Stb6vg
```
C’est ce format qui a été utilisé jusque là dans Cesium. Il est à la fois suffisamment court (44 caractères ou moins) et facile à lire (il n’utilise pas de caractères spéciaux comme “`+?@,/:!...`”.
### Utilisation courante
Mais on s’est aperçu que ce format posait problème parce qu’il ne protège pas contre les erreurs de copier-coller. C’est pour ça que récemment, on a ajouté une “checksum” à la fin, séparée par “:”.
```auto
# même clé mais avec une checksum à la fin
FHNpKmJrUtusuvKPGomAygQqeiks98bdV6yD61Stb6vg:J82
```
Cette checksum est optionnelle, mais elle permet à Cesium vérifier que l’utilisateur n’a pas fait de faute en copiant la clé.
> [@Spiranne](#):
>
> garder en mémoire [une partie de la] clé publique
C’est effectivement une bonne manière de faire une vérification rapide “à l’œil”. En effet, une toute petite erreur dans les identifiants génère toujours une grosse différence dans la clé publique. Cette différence sera tout de suite visible si on retient quelques caractères.
> [@Spiranne](#):
>
> J’ai lu quelque part qu’elle resterait visible sur Césium2 : est-ce confirmé ?
Oui, effectivement, pour ne pas perdre les utilisateurs, on va continuer à afficher ce format de clé, au moins pendant un moment.
### Nouveau format de clé publique : les addresses SS58
> [@Spiranne](#):
>
> au sujet de la “nouvelle forme de clé publique”
J’aimerais démystifier ce nouveau format. Un autre problème du format actuel de clé publique est qu’il ne distingue pas les réseaux. Si on utilise à la fois la g1-test et la g1, l’adresse sera la même. On pourrait donc ajouté une autre information dans la clé, comme un préfixe avec le nom du réseau “`g1::checksum`”. Mais une solution existe déjà dans le framework substrate, c’est le format “SS58”. C’est ce format qu’on appelle ici “nouvelle forme de clé publique”. Ce format est composé d’un préfixe correspondant au réseau (gdev, g1, polkadot…), de la clé publique, et d’une checksum. Mais plutôt qu’être séparé par des “`:`”, il sont juxtaposés en binaire (ici noté en hexadécimal) :
```auto
# préfixe du réseau (ici "42" pour le réseau de test)
2a
# clé publique (identique à précédemment)
d43593c715fdd31c61141abd04a99fd6822c8558854ccde39a5684e7a56da27d
# checksum (blake2, cf post "manipulation d'adresse ss58")
1d21
```
Quand on prend tous ces octets et qu’on les note en base 58, on obtient la clé suivante :
```auto
# clé publique pure comme définie au début
FHNpKmJrUtusuvKPGomAygQqeiks98bdV6yD61Stb6vg
# adresse au format ss58 (préfixe=42, clé publique, checksum)
5GrwvaEF5zXb26Fz9rcQpDWS57CtERHpNehXCPcNoHGKutQY
# adresse au format ss58 (préfixe=4450, ...)
g1Pn1geRZnHcVdWdKkoYwQrAARDTXK1D7H3zuXj7GNayT1thu
```
Comme le préfixe de réseau est présent au début, toutes les adresses sur le réseau de test commenceront par “5”. Et on a choisi le préfixe SS58 de la Ğ1 pour que les adresses commencent par “g1”, cf :
- [Choix du préfixe SS58 pour nos blockchains substrate](https://forum.duniter.org/t/choix-du-prefixe-ss58-pour-nos-blockchains-substrate/9068)
- [Quel préfixe pour les futures clefs publiques G1 ? sondage - Outils - Support utilisateur - Forum Monnaie Libre](https://forum.monnaie-libre.fr/t/quel-prefixe-pour-les-futures-clefs-publiques-g1-sondage/21348)
Comme on est sur le forum technique, je me suis permis une réponse plus complète et plus technique. Maintenant que vous savez tout, à vous de vulgariser !
---
### Author:  [@Spiranne](https://forum.duniter.org/u/Spiranne)
#### Post date: [17 October 2024 13:28 UTC](https://forum.duniter.org/t/format-de-cle-et-verification/12574/4 "2024-10-17T13:28:58Z")
Merci de ta réponse très technique !
je pense qu’on ne pourra pas communiquer cela dans la comm mise à jour V2… Enfin pas pour le moment,
mais je garde sous le coude ton post car j’ai une petite idée de la manière de le vulgariser mais plus tard.
Il se pourrait qu’il y ait des questions là-dessus, après décantation suite à la bascule.
---
### Author:  [@Nicolas80](https://forum.duniter.org/u/Nicolas80)
#### Post date: [13 January 2025 12:57 UTC](https://forum.duniter.org/t/format-de-cle-et-verification/12574/5 "2025-01-13T12:57:57Z")
Je viens seulement de trouver ce post pour les adresses SS58 que l’on va utiliser en G1 (de prod) avec la v2…
Du coup, je me demande quels clients G1v2 supportent ce préfix comme point de configuration ?
J’ai regardé rapidement dans GCli, je ne vois nulle part ou on précise le `Ss58AddressFormat` et du coup il utilise celui par défaut: `Ss58AddressFormatRegistry::SubstrateAccount` (= 42u16).
Egalement une autre question pour le réseau “gtest”; est-ce que l’on utilisera toujours le même préfix Substrate (42) ?
Edit: Pour info dans GCli, le préfix pour G1 de prod est bien disponible dans les sources que l’on a en dépendance: `Ss58AddressFormatRegistry::G1Account` (= 4450u16) mais pas utilisé dans GCli actuellement.
---
### Author:  [@Moul](https://forum.duniter.org/u/Moul)
#### Post date: [13 January 2025 13:40 UTC](https://forum.duniter.org/t/format-de-cle-et-verification/12574/6 "2025-01-13T13:40:52Z")
> [@Nicolas80](#):
>
> Egalement une autre question pour le réseau “gtest”; est-ce que l’on utilisera toujours le même préfix Substrate (42) ?
Oui, c’est la convention Substrate, les réseaux de test ont le préfixe 42.
La véritable monnaie Ğ1 de production en v2 aura [le préfixe `4450`](https://forum.duniter.org/t/choix-du-prefixe-ss58-pour-nos-blockchains-substrate/9068/42).
---
### Author:  [@tuxmain](https://forum.duniter.org/u/tuxmain)
#### Post date: [13 January 2025 16:50 UTC](https://forum.duniter.org/t/format-de-cle-et-verification/12574/7 "2025-01-13T16:50:38Z")
Comme les runtime metadata pourront différer entre gdev et g1, il faudra trouver un moyen pour que les clients gèrent les différentes chaînes. Soit gérer les deux, soit faire plusieurs exécutables différents.
Donc gérer différentes chaînes ne se résume malheureusement pas à pouvoir changer le préfixe et les adresses de nœuds.
Cela dit ce serait utile de pouvoir changer le préfixe d’une adresse donnée.
---
### Author:  [@poka](https://forum.duniter.org/u/poka)
#### Post date: [13 January 2025 17:02 UTC](https://forum.duniter.org/t/format-de-cle-et-verification/12574/8 "2025-01-13T17:02:18Z")
Côté Ğecko je compte faire autant d’app différentes que de réseau, via ce qu’on appel des flavors (des saveurs) pour des apps mobiles.
Sur les stores grand publique il n’y aura que les apps branchés sur de vrai monnaies en production, pour la moment, la Ğ1.
Les autres seront installable via les liens de postes et gitlab, les listes testFlight pour ios, éventuellement f-droid et autre stores alternatifs en fonction des contributions, comme actuellement.