# Somme de contrôle de la clé publique
**URL:** https://forum.duniter.org/t/somme-de-controle-de-la-cle-publique/7616
**Category:** Applications
**Tags:** pubkey\_checksum
**Created:** [27 September 2020 13:21 UTC](https://forum.duniter.org/t/somme-de-controle-de-la-cle-publique/7616 "2020-09-27T13:21:46Z")
**Posts on this page:** 3
**Page:** 4
### Author:  [@tuxmain](https://forum.duniter.org/u/tuxmain)
#### Post date: [2 July 2021 17:37 UTC](https://forum.duniter.org/t/somme-de-controle-de-la-cle-publique/7616/62 "2021-07-02T17:37:41Z")
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).
---
### Author:  [@Moul](https://forum.duniter.org/u/Moul)
#### Post date: [3 July 2021 07:18 UTC](https://forum.duniter.org/t/somme-de-controle-de-la-cle-publique/7616/63 "2021-07-03T07:18:44Z")
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.
> **[Cyclic redundancy check](https://en.wikipedia.org/wiki/Cyclic_redundancy_check)**
>
> A cyclic redundancy check (CRC) is an error-detecting code commonly used in digital networks and storage devices to detect accidental changes to digital data. Blocks of data entering these systems get a short check value attached, based on the remainder of a polynomial division of their contents. On retrieval, the calculation is repeated and, in the event the check values do not match, corrective action can be taken against data corruption. CRCs can be used for error correction (see bitfilters...
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`.
> [@matograine](#):
>
> le fait de n’utiliser **qu’une passe de sha256**. (l’argument de @1000i100 m’a convaincu : si ça change, autant que ça change pour tout le monde.)
> [@matograine](#):
>
> ```auto
> hashlib.sha256(hashlib.sha256(pubkey_byte).digest()).digest()
>
> ```
>
> La double passe de sha256, c’est pour le checksum défini par Tortue. Qu’on soit bien sûr de ce dont on parle.
À creuser…
---
### Author:  [@tuxmain](https://forum.duniter.org/u/tuxmain)
#### Post date: [3 July 2021 07:40 UTC](https://forum.duniter.org/t/somme-de-controle-de-la-cle-publique/7616/64 "2021-07-03T07:40:11Z")
> [@Moul](#):
>
> potentiellement affaiblissant l’algorithme
D’après [ceci](https://crypto.stackexchange.com/questions/87434/is-double-sha-256-the-best-choice-for-bitcoin), 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.
[Previous page](https://forum.duniter.org/t/somme-de-controle-de-la-cle-publique/7616.md?page=3)