C’est corrigé, tu verras que le padding est aléatoire, c’est pour des raisons de sécurité, si on sait que le padding est à zéro on peut deviner une parie de la clé de chiffrement !
Ok, bon ben je ne peux pas tester avec le base64 dans un test automatisé, puisque les fonctions ne sont plus déterministes. J’avais salement rusé pour le nonce, mais je vais changer de stratégie pour le test unitaire et ne tester que la partie déterministe des bytes du Dewif. Je te dirais si je vois un problème.
[edit]
J’ai fixé une typo (MR à valider et merger)
C’est bon, les exemples passent ! RFC implémentée !
J’ai eu le même problème, j’ai contourné avec une fonction gen_nonce qui est aléatoire où non selon qu’on est en test : crypto/src/dewif.rs · master · libs / dubp-rs-libs · GitLab
Quant aux « unused bytes », ils n’ont pas besoin d’être strictement aléatoires, il faut juste qu’un attaquant ne puisse pas connaître la valeur des « unused bytes » sans connaître le secret.
Perso je les remplis avec le hash sha256 de l’entropie au moins c’est déterministe 
C’est mergé
Nickel, si rien ne change dans les prochaines semaines je mergerai enfin cette RFC !
1 Like
Après un dur labeur, une vraie torture pour comprendre comment implémenter la RFC 13, et surtout grâce à l’aide de son implémentation dans Tikka faite par @vit, j’ai enfin un résultat concordant pour la génération d’un DEWIF en reprenant l’exemple 2 de la RFC, en Dart:
$ dart run bin/duniter_crypto_dart.dart
crop cash unable insane eight faith inflict route frame loud box vibrant
Data is conform to RFC !
AAAAARAAAAEOAcVCma5x/ipOzcfViufNdfj5k4Sl5zdrHLf9PPGDkH1Pz3y8tFrx/jZZcJd92LIk+EWIrjxiSw==
Honnêtement, sans prendre exemple sur l’implémentation de Vit, c’était peine perdu, même en relisant l’intégralité de ce thread, car je ne sais pas comment tu as deviné comment formater le header de la chaine, je ne vois ça nul part dans la RFC, j’ai dû rater quelques chose … Quelqu’un d’autre a-il déjà implémenté cette RFC ?
Il faudrait peut être le préciser.
(edit: Bon en relisant attentivement la RFC, c’est en effet indiqué, autant pour moi, je devais pas avoir les yeux en face des trous…)
Implémenter cette RFC ma rendu triste, vraiment…
Il fallait que je vous l’exprime ^^
(bon hormis le header inconnu, c’est aussi parce-que j’ai mis un certain temps pour me rendre compte que mes concaténations binaires n’étaient pas correctes en type Uint8List, ça allait mieux quand j’ai commencé à tout concaténer en hexa)
Maintenant je peux attaquer le déchiffrement du mnemonic à partir du DEWIF, ça devrait être plus facile dans l’autre sens. (Tu ne la pas fait @vit ? Je ne trouve pas cette partie dans le code de Tikka).
edit: Il reste cependant 2 choses que j’ai inscrites en dur dans le code concernant la moulinette scrypt, en reprenant les valeurs de l’exemple 2 de la RFC.
Malgré mes lectures je n’ai pas compris comment faire autrement:
-
log_n = 14;: Malgré l’explication d’elois, j’ai pas compris. Comment deviner le paramètre d’entrée de scrypt ? -
desired_key_length = 42: Je sais que c’est la réponse à la grande question sur la vie, l’univers et le reste, mais sans l’exemple 2 de la RFC, je n’aurais jamais deviner quoi même.
Je suppose qu’inscrire ces valeurs en dur est la seule chose à faire, mais je ne saurais l’affirmer.
Ces 2 choses devraient selon moi être expliqués dans la RFC pour éviter que les prochains aventurier galèrent autant que moi, à devoir relire tout ce thread sans trouver de réponses…
1 Like
Le code pour relire un dewif est dans data/signing_key.py :
Pas facile à trouver, car une paire de clef est un objet (une donnée donc dans data) et on utilise la programmation Orientée Objet pour créer la clef depuis un fichier, via une méthode dédiée de l’objet.
Je déteste de plus en plus la programmation orientée objet à cause de ça. On mélange données et fonctions dans la même entité. Maintenant, moi je sépare les deux dans tous mes projets. J’ai des objets qui n’ont que des propriétés et des objets qui n’ont que des fonctions (autant que possible).
Rust n’est pas OOP (même si on peut en faire en mettant des fonctions dans une structure, mais je le déconseille fortement).
Les constantes pour scrypt sont effectivement dans les exemples.
1 Like
Il me semble que 42 avait été fixé comme la plus petite taille de clé acceptée. Les clés de toutes tailles sont possibles (commençant par des 0x00, ou 1 en base58), mais celles de 42 caractères sont déjà rares. (44 et 43 étant les deux tailles rencontrées en pratique)
1 Like