# Encodage des documents
**URL:** https://forum.duniter.org/t/encodage-des-documents/3596
**Category:** Dunitrust
**Created:** [10 November 2017 13:00 UTC](https://forum.duniter.org/t/encodage-des-documents/3596 "2017-11-10T13:00:40Z")
**Posts on this page:** 20
**Page:** 2
### Author:  [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [14 November 2017 10:44 UTC](https://forum.duniter.org/t/encodage-des-documents/3596/21 "2017-11-14T10:44:35Z")
> [@nanocryk](#):
>
> Mais là, je cherche surtout à être compatible avec l’implémentation actuelle.
Ce qui est tout à fait possible : les détails d’implémentation techniques tu peux déjà les retrouver par toi-même dans le code (ici, TypeScript, Python ou même JavaScript puisque Cesium implémente aussi l’algo).
> [@nanocryk](#):
>
> J’essaye de suivre au maximum le document du protocole, mais ces informations sont manquantes (à rajouter ?).
D’autres n’ont pas eu ce sentiment, ou bien ne l’ont pas manifesté. Si toutefois tu le ressens, alors tu peux proposer d’intégrer ces informations à travers une contribution (Pull Request).
> [@nanocryk](#):
>
> S’il y a des tests unitaires autour des signatures et des clés, je les veux bien.
Tu pourrais simplement chercher, tu sais le faire, j’en suis sûr.
---
### Author:  [@nanocryk](https://forum.duniter.org/u/nanocryk)
#### Post date: [14 November 2017 10:58 UTC](https://forum.duniter.org/t/encodage-des-documents/3596/22 "2017-11-14T10:58:25Z")
> [@cgeek](#):
>
> D’autres n’ont pas eu ce sentiment, ou bien ne l’ont pas manifesté. Si toutefois tu le ressens, alors tu peux proposer d’intégrer ces informations à travers une contribution (Pull Request).
Je le ferais avec plaisir.
> [@cgeek](#):
>
> Tu pourrais simplement chercher, tu sais le faire, j’en suis sûr.
J’ai regardé en TypeScript et en Python, mais je n’ai pas trouvé ce que je cherchais. J’ai voulu regarder du côté de Cesium, mais je n’ai pas trouvé où se situe la “logique” du programme.
Dans mon code actuel, j’ai des wrapper pour les clés publiques et privées qui testent la taille de la data, et qui peuvent être transformé en Base58 dans les 2 sens. J’utilise une bibliothèque pour faire la conversion, mais je veux tester avec des adresses valides pour ne pas avoir de mauvaises surprises plus tard, et je ne trouve pas d’équivalent dans les différentes sources citées.
Tu m’as déjà fourni tout ce dont j’ai besoin pour continuer, il ne me manque plus que ça. Je pourrais passer ce test car il a peu de chance d’échouer, mais ça ne serait clairement pas une bonne pratique. Tout code écrit doit être testé pour vérifier qu’il fait ce qu’il doit faire 😛.
---
### Author:  [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [14 November 2017 11:26 UTC](https://forum.duniter.org/t/encodage-des-documents/3596/23 "2017-11-14T11:26:33Z")
[https://github.com/duniter/duniter/blob/59f050e170c6c8b183dfe5389b403007fa2e9033/test/fast/modules/common/crypto.js](https://github.com/duniter/duniter/blob/59f050e170c6c8b183dfe5389b403007fa2e9033/test/fast/modules/common/crypto.js)
---
### Author:  [@nanocryk](https://forum.duniter.org/u/nanocryk)
#### Post date: [14 November 2017 11:53 UTC](https://forum.duniter.org/t/encodage-des-documents/3596/24 "2017-11-14T11:53:34Z")
Je veux justement tester
```auto
pub = base58.decode(keyPair.publicKey);
sec = base58.decode(keyPair.secretKey);
```
J’ai rajouté une couche intermédiaire pour empêcher d’avoir des clés publiques/privées de taille invalide. Je veux donc écrire les tests des situations qui doivent échouer, et de celles qui doivent marcher (avec la relation Base58 \<-\> raw valide).
J’ai trouvé un moyen de tester ça sans prendre trop de risque, mais ça aurait été bien de prendre des valeurs issues de vos versions pour être sûr qu’elles sont compatibles.
---
### Author:  [@nanocryk](https://forum.duniter.org/u/nanocryk)
#### Post date: [14 November 2017 12:19 UTC](https://forum.duniter.org/t/encodage-des-documents/3596/25 "2017-11-14T12:19:08Z")
Voila mon test en Rust :
```auto
#[test]
fn base58_public_key() {
let public58 = "DNann1Lh55eZMEDXeYt59bzHbA3NJR46DeQYCS2qQdLV";
let public_key = PublicKey::from_base58(public58).unwrap();
let public_raw = public58.from_base58().unwrap();
for (key, raw) in public_key.0.iter().zip(public_raw.iter()) {
assert_eq!(key, raw);
}
assert_eq!(PublicKey::from_base58("DNann1Lh55eZMEDXeYt59bzHbA3NJR46DeQYCS2qQdLVdjq").unwrap_err(), KeyBase58Error::InvalidKeyLendth(35, 32));
assert_eq!(PublicKey::from_base58("DNann1Lh55eZMEDXeYt59bzHbA3NJR46DeQYCS2qQd").unwrap_err(), KeyBase58Error::InvalidKeyLendth(31, 32));
assert_eq!(PublicKey::from_base58("DNann1Lh55eZMEDXeYt59bzHbA3NJR46DeQYCS2qQd<<").unwrap_err(), KeyBase58Error::InvalidCharacter('<', 42));
}
```
Ce dont je veux m’assurer, c’est d’avoir la même valeur de `public_raw` (tableau de `u8`) que vous.
---
### Author:  [@Inso](https://forum.duniter.org/u/Inso)
#### Post date: [14 November 2017 12:49 UTC](https://forum.duniter.org/t/encodage-des-documents/3596/26 "2017-11-14T12:49:15Z")
> [@nanocryk](#):
>
> Ce dont je veux m’assurer, c’est d’avoir la même valeur de public\_raw (tableau de u8) que vous.
Je l’aurais fait différemment : est-ce que la clé produit bien la même signature sur un document donné ?
Là, on dirait que tu cherches à tester ton encodeur base58. Ca me parait plus pertinent de tester directement le fonctionnement qui impacte le protocole Duniter 🙂
---
### Author:  [@nanocryk](https://forum.duniter.org/u/nanocryk)
#### Post date: [14 November 2017 12:50 UTC](https://forum.duniter.org/t/encodage-des-documents/3596/27 "2017-11-14T12:50:00Z")
C’est en cours, mais j’aimerais tester à tous les niveaux 😉
Mais du coup oui si ce test passe alors la data est là même.
> [@Inso](#):
>
> Là, on dirait que tu cherches à tester ton encodeur base58. Ca me parait plus pertinent de tester directement le fonctionnement qui impacte le protocole Duniter 🙂
Passe voir le [fichier en question](https://github.com/duniter-rs/protocol/blob/feature/document/src/keys.rs). Je fais une conversion d’un `Vec` en `[u8;32]` ou `[u8;64]`, plus des vérifications de taille. Ca me semble donc normal de vouloir vérifier ce comportement particulier.
---
### Author:  [@Inso](https://forum.duniter.org/u/Inso)
#### Post date: [14 November 2017 12:55 UTC](https://forum.duniter.org/t/encodage-des-documents/3596/28 "2017-11-14T12:55:58Z")
Effectivement 🙂
Alors tu peux tester un comportement bijectif pour ton développement particulier (decode \<=\> encode -\> toujours la même valeur)
Pour la compatibilité avec nous, tu vérifies simplement les signatures et ça sera bon 🙂
---
### Author:  [@nanocryk](https://forum.duniter.org/u/nanocryk)
#### Post date: [14 November 2017 12:57 UTC](https://forum.duniter.org/t/encodage-des-documents/3596/29 "2017-11-14T12:57:25Z")
Exactement ! J’aurais bientôt les signatures. J’ai oublié de tester `to_base58()`, merci de m’y faire penser.
---
### Author:  [@nanocryk](https://forum.duniter.org/u/nanocryk)
#### Post date: [14 November 2017 13:31 UTC](https://forum.duniter.org/t/encodage-des-documents/3596/30 "2017-11-14T13:31:35Z")
Signature correcte, tout est bon !
Code : [https://github.com/duniter-rs/protocol/blob/feature/document/src/keys.rs](https://github.com/duniter-rs/protocol/blob/feature/document/src/keys.rs)
Tests unitaires :
```auto
PS D:\Bibliotheques\Documents\Projets\Autres\rust\duniter-rs\protocol> cargo test
Compiling duniter-rs-protocol v0.0.0 (file:///D:/Bibliotheques/Documents/Projets/Autres/rust/duniter-rs/protocol)
Finished dev [unoptimized + debuginfo] target(s) in 1.54 secs
Running target\debug\deps\duniter_rs_protocol-39d1bc1200746998.exe
running 4 tests
test keys::tests::base64_signature ... ok
test keys::tests::base58_public_key ... ok
test keys::tests::base58_private_key ... ok
test keys::tests::message_sign_verify ... ok
test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
```
Je vais pouvoir attaquer le wrapper des documents.
---
### Author:  [@nanocryk](https://forum.duniter.org/u/nanocryk)
#### Post date: [7 January 2018 14:55 UTC](https://forum.duniter.org/t/encodage-des-documents/3596/31 "2018-01-07T14:55:15Z")
25 messages ont été déplacés vers un nouveau sujet : [Discussions autour du developpement de duniter-rs (Duniter en Rust)](https://forum.duniter.org/t/discussions-autour-du-developpement-de-duniter-rs-duniter-en-rust/3930)
---
### Author:  [@nanocryk](https://forum.duniter.org/u/nanocryk)
#### Post date: [14 November 2017 15:45 UTC](https://forum.duniter.org/t/encodage-des-documents/3596/35 "2017-11-14T15:45:23Z")
Avec la crate que j’utilise la génération des clés se fait avec une seed, et ça n’a l’air de marcher que si elle fait 32 octets.
Quelle opérations vous faites avec le `secret id` et le `password` pour obtenir votre seed ?
---
### Author:  [@Inso](https://forum.duniter.org/u/Inso)
#### Post date: [14 November 2017 15:59 UTC](https://forum.duniter.org/t/encodage-des-documents/3596/36 "2017-11-14T15:59:36Z")
On utilise scrypt ( [https://github.com/duniter/duniter-python-api/blob/master/duniterpy/key/signing\_key.py](https://github.com/duniter/duniter-python-api/blob/master/duniterpy/key/signing_key.py) ) qui est dispo dans ce crate : [https://github.com/DaGenix/rust-crypto](https://github.com/DaGenix/rust-crypto)
---
### Author:  [@nanocryk](https://forum.duniter.org/u/nanocryk)
#### Post date: [14 November 2017 16:41 UTC](https://forum.duniter.org/t/encodage-des-documents/3596/37 "2017-11-14T16:41:53Z")
C’est justement la crate que j’utilise, parfait !
---
### Author:  [@nanocryk](https://forum.duniter.org/u/nanocryk)
#### Post date: [15 November 2017 09:01 UTC](https://forum.duniter.org/t/encodage-des-documents/3596/38 "2017-11-15T09:01:36Z")
D’où viennes ces [paramètres](https://github.com/duniter/duniter-python-api/blob/066112eff4d5e216d75f6e3a3d0c63a16e73f28a/duniterpy/key/signing_key.py#L16) ?
Je fais pareil, je laisse le code appellant les donner ? Ou je peux déjà les fixer dans mon code ?
EDIT : Je viens de voir dans `encryption_key.py` :
```auto
SCRYPT_PARAMS = {'N': 4096,
'r': 16,
'p': 1
}
```
Est-ce que c’est le seul endroit où ils sont définis, auquel cas je peux fixer leur valeur dans mon wrapper, ou alors je laisse la possibilité de passer d’autres valeurs ?
De plus, dans la crate Rust, [`N` est un `u8` (nombre non signé sur 8bits)](https://docs.rs/rust-crypto/0.2.36/crypto/scrypt/struct.ScryptParams.html), et bien évidement n’est pas content quand je lui passe `4096` … Une idée ?
EDIT 2 : Je viens de comprendre, il faut donner le `log2(N)`, ce qui donne une valeur de 12. Ca m’apprendra à lire un peu trop vite la doc.
EDIT 3 : Ca fonctionne très bien, par contre le passage des paramètres est assez lourd. Après il me semble que mon code se situe au même niveau que celui où sont défini ces paramètres, du coup je pense que les gérer en interne à ce module est correct. D’ailleurs, je suppose que si on change ces paramètres, la paire de clés n’est plus la même. Du coup, il vaut mieux que ça soit fixé à un unique endroit. Pour que ça soit plus clair, je vais ajouter des constantes en haut de fichier pour pouvoir les trouver plus facilement.
Voilà du coup la [version fonctionnelle avec mot de passe et sel de hachage](https://github.com/duniter-rs/protocol/blob/feature/document/src/keys.rs). Il y a l’exemple d’utilisation dans la doc tout en haut, qui sert aussi de test unitaire. Tu peux exécuter les tests avec `cargo test`, et générer là doc avec `cargo doc --no-deps` qui se trouvera dans `./target/doc/duniter_rs_protocol`.
---
### Author:  [@Inso](https://forum.duniter.org/u/Inso)
#### Post date: [15 November 2017 14:05 UTC](https://forum.duniter.org/t/encodage-des-documents/3596/39 "2017-11-15T14:05:39Z")
> [@nanocryk](#):
>
> Est-ce que c’est le seul endroit où ils sont définis, auquel cas je peux fixer leur valeur dans mon wrapper, ou alors je laisse la possibilité de passer d’autres valeurs ?
Il vaut mieux laisser la possibilité de changer les valeurs. C’est une erreur de Encryption Key que de les avoir écrite sen dur.
Regarde la signing\_key : [duniter-python-api/duniterpy/key/signing\_key.py at master · duniter/duniter-python-api · GitHub](https://github.com/duniter/duniter-python-api/blob/master/duniterpy/key/signing_key.py#L28)
> D’ailleurs, je suppose que si on change ces paramètres, la paire de clés n’est plus la même.
Oui, il est possible de les modifier dans Sakia, Duniter ainsi que Cesium il me semble.
---
### Author:  [@nanocryk](https://forum.duniter.org/u/nanocryk)
#### Post date: [15 November 2017 14:27 UTC](https://forum.duniter.org/t/encodage-des-documents/3596/40 "2017-11-15T14:27:22Z")
> [@Inso](#):
>
> Il vaut mieux laisser la possibilité de changer les valeurs.
D’accord. je pourrais faire une struct “générateur de clé” qui prend ces paramètres, et qui permet de générer les clés avec salt+pass. Ca serait même beaucoup plus propre qu’avec une bête fonction 😛
---
### Author:  [@nanocryk](https://forum.duniter.org/u/nanocryk)
#### Post date: [16 November 2017 09:01 UTC](https://forum.duniter.org/t/encodage-des-documents/3596/41 "2017-11-16T09:01:45Z")
Je viens de voir ce post là :
[https://forum.duniter.org/t/version-0-60-0-protocole-final/1486/2?u=cgeek](https://forum.duniter.org/t/version-0-60-0-protocole-final/1486/2?u=cgeek)
Les paramètres de génération de clé sont donc bien réglables, cependant dans mon code je ne pourrais avoir que des `N = 2^i`, vu que la fonction `crypto::scrypt::ScryptParams::new` demande `log2(N)` et non `N`. Après je ne pense pas que ça soit un trop gros problème, vu que la génération de clés n’est pas dans le protocole et que ces paramètres n’impactent en rien l’utilisation des clés.
Je vais faire l’ajout d’un générateur de clé pour simplifier ce procédé, et ensuite vous pourrez me donner votre avis sur mon implémentation ? 🙂
---
### Author:  [@Inso](https://forum.duniter.org/u/Inso)
#### Post date: [16 November 2017 09:47 UTC](https://forum.duniter.org/t/encodage-des-documents/3596/42 "2017-11-16T09:47:29Z")
> [@nanocryk](#):
>
> Les paramètres de génération de clé sont donc bien réglables, cependant dans mon code je ne pourrais avoir que des N = 2^i, vu que la fonction crypto::scrypt::ScryptParams::new demande log2(N) et non N. Après je ne pense pas que ça soit un trop gros problème, vu que la génération de clés n’est pas dans le protocole et que ces paramètres n’impactent en rien l’utilisation des clés.
C’est pareil côté Sakia, on ne peut utiliser que des puissances de 2 🙂
> [@nanocryk](#):
>
> Je vais faire l’ajout d’un générateur de clé pour simplifier ce procédé, et ensuite vous pourrez me donner votre avis sur mon implémentation ? 🙂
Pas de soucis !
---
### Author:  [@nanocryk](https://forum.duniter.org/u/nanocryk)
#### Post date: [16 November 2017 10:34 UTC](https://forum.duniter.org/t/encodage-des-documents/3596/43 "2017-11-16T10:34:58Z")
C’est fait.
Si tu as l’environnement Rust d’installé (`rustup`), tu peux :
- Lancer les tests unitaires avec `cargo test`
- Générer la documentation avec `cargo doc --no-deps` qui se trouvera dans `./target/doc/duniter_rs_protocol/index.html`
J’ai mis pas mal de liens de la doc pour que ça soit assez compréhensible.
Si tu as la moindre suggestion n’hésite pas 🙂
EDIT : Wrapper spécifique pour les documents du type `Identity` terminé. Je compte en faire un pour chaque document et de cette façon m’assurer que les champs sont toujours dans le bon ordre.
[Previous page](https://forum.duniter.org/t/encodage-des-documents/3596.md?page=1)
[Next page](https://forum.duniter.org/t/encodage-des-documents/3596.md?page=3)