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).
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).
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 .
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.
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
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.
Passe voir le fichier en question. Je fais une conversion d’un Vec<u8> en [u8;32] ou [u8;64], plus des vérifications de taille. Ca me semble donc normal de vouloir vérifier ce comportement particulier.
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.
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 ?
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 ?
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.
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 ?
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.