On utilise scrypt ( 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
1 Like
C’est justement la crate que j’utilise, parfait !
D’où viennes ces paramètres ?
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 :
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), 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. 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.
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
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.
1 Like
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 
Je viens de voir ce post là :
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 ? 
C’est pareil côté Sakia, on ne peut utiliser que des puissances de 2 
Pas de soucis !
1 Like
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-depsqui 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.
1 Like
@cgeek Vu que l’on est à la version 10 du protocole, je suppose que la version à changé au cours de la vie de Ǧ1, non ? Pour pouvoir vérifier les blocs selon les anciennes règles, il faut du coup que j’implémente les vérifications pour les anciennes versions ?
La première version de la Ǧ1 était déja la 10 
https://g1.duniter.org/blockchain/block/0
Elle a évolué pendant le cycle de vie des monnaies précédentes (meta brouzouf, zeta brouzouf, etc)
Pour la première monnaie de production, on est passé à la version 10.
Du coup je n’ai besoin d’implémenter que la 10.
J’ai fait un module v10, comme ça ça me permettra de pouvoir appliquer les bonnes règles en cas de changement.
1 Like
Oui typiquement pour Duniter 2.0 les documents vont passer en v11 !
Sur la branche feature/documents j’ai l’erreur suivante :
inso at archlinux in ~/code/duniter-rs/protocol (feature/document)
$ cargo test
Updating registry `https://github.com/rust-lang/crates.io-index`
Downloading rust-crypto v0.2.36
Downloading linked-hash-map v0.5.0
Downloading base64 v0.7.0
Downloading base58 v0.1.0
Downloading time v0.1.38
Downloading libc v0.2.33
Downloading rand v0.3.18
Downloading rustc-serialize v0.3.24
Downloading gcc v0.3.54
Downloading safemem v0.2.0
Downloading byteorder v1.1.0
Compiling linked-hash-map v0.5.0
Compiling base58 v0.1.0
Compiling libc v0.2.33
Compiling rustc-serialize v0.3.24
Compiling gcc v0.3.54
Compiling byteorder v1.1.0
Compiling safemem v0.2.0
Compiling rand v0.3.18
Compiling time v0.1.38
Compiling base64 v0.7.0
Compiling rust-crypto v0.2.36
Compiling duniter-rs-protocol v0.0.0 (file:///home/inso/code/duniter-rs/protocol)
error[E0599]: no function or associated item named `from_hex` found for type `blocks::BlockHash` in the current scope
--> src/blocks.rs:96:9
|
96 | BlockHash::from_hex("E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855").unwrap();
| ^^^^^^^^^^^^^^^^^^^
|
= help: items from traits can only be used if the trait is implemented and in scope
= note: the following trait defines an item `from_hex`, perhaps you need to implement it:
candidate #1: `rustc_serialize::hex::FromHex`
warning: unused variable: `text`
--> src/blocks.rs:28:16
|
28 | pub fn new(text: &str) -> BlockHash {
| ^^^^
|
= note: #[warn(unused_variables)] on by default
= note: to disable this warning, consider using `_text` instead
error: aborting due to previous error
error: Could not compile `duniter-rs-protocol`.
warning: build failed, waiting for other jobs to finish...
error: build failed
Une idée ?
Tu bosses avec quelle toolchain d’ailleurs ? La stable ou la nightly ?
En stable.
C’est normal, mon dernier commit est un work in progress car je devais changer de PC. Tu pourras tester avec le commit précédent normalement.
Bien vu
inso at archlinux in ~/code/duniter-rs/protocol (7a32fa3...●●)
$ cargo test
Compiling duniter-rs-protocol v0.0.0 (file:///home/inso/code/duniter-rs/protocol)
Finished dev [unoptimized + debuginfo] target(s) in 4.96 secs
Running target/debug/deps/duniter_rs_protocol-198a2beeb6cfecb0
running 6 tests
test keys::tests::base58_public_key ... ok
test keys::tests::base64_signature ... ok
test keys::tests::base58_private_key ... ok
test documents::v10::members::tests::real_identity_document_signature ... ok
test documents::tests::real_document_signature ... ok
test keys::tests::message_sign_verify ... ok
test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
Doc-tests duniter-rs-protocol
running 2 tests
test src/documents/mod.rs - documents::GenericDocumentBuilder (line 185) ... ok
test src/keys.rs - keys (line 8) ... ok
test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
La génération de la doc fonctionne bien, c’est super propre, ça donnerait envie de se mettre au Rust !
Tes documents Builder vont aussi avoir la capacité de construire un document à partir de ses attributs ?
2 Likes
C’est à dire ? Quand tu regarde l’utilisation de IdentityDocument, tu dois d’abord le créer avec tous les attributs, puis ajouter la signature (deja connue quand tu reconstitue un document valide; ou créé avec la clé privée). C’est bien ce dont tu me parle ?
1 Like
Effectivement, j’ai lu trop vite. C’est bien ça
Pourquoi avoir appelé le fichier member.rs ? Il contient la description des documents Identity pourtant ?
Il contiendra aussi les documents de certification et de révocation C’est pour faire une séparation avec les documents relatifs aux blocs et transactions.
Ca ne risque pas de faire de gros fichiers à la fin ?
Pas forcément. Après chaque fichier correspond à un module, et avec un module composé d’1 ou 2 petites structs est assez redondant. On peut sinon faire plein de petits modules pour séparer les comportements, et dans le module parent réexporter avec un pub use les types. Habituellement c’est utilisé pour exposer les types vraiment importants pour ne pas aller les chercher au fin fond de la hiérarchie.
Dans tous les cas pour 3 ou 4 petites structs ça ne me semble pas nécessaire de les faire dans des fichiers différents, surtout quand elle ont un rapport
1 Like