Je suis entrain de regarder comment dans cesium (ou duniter ou gannonce, ou gchange ou…) est fait le passage des identifiant secret (salt) et mot de passe vers clef publique et privée.
Dans cesium au moins, c’est la libsodium qui semble être utilisée.
Je vois qu’il en existe une réécriture dédiée au JS, plus légère et très très largement utilisé : tweetnacl. Que ce soit avec l’une ou avec l’autre, si l’un de vous sais me dire quoi mettre comme scryptParams pour générer correctement les clefs, ça me fera gagner du temps par rapport à fouiller dans le code jusqu’a trouver.
// extrait adapté/résumé du code de cesium à ce sujet :
const keypair = await CryptoUtils.scryptKeypair(idSecret, mdp, scryptPrams);
const pubkey = CryptoUtils.util.encode_base58(keypair.signPk);
Outre le fait qu’il va falloir que je vois quel branchement faire pour avoir un équivalent de CryptoUtils avec une chaine de dépendance bien plus contenu que dans Cesium, il me manque les algo utilisé à indiquer je suppose dans scriptParams pour obtenir le bon résultat dans pubkey à partir des idSecret et mdp à tester.
Je ne sais pas pour la version js, mais cette partie à été réécrite de manière consise en Rust, peut-être que ça pourras t’aider (il y a les valeurs par defaut de scriptParam).
Pour ton histoire de chaine de dépendence je n’ai par contre rien compris à ta phrase xD
Alors attention @1000i100 le code Rust de @nanocryk ne donne pas la même keypair pour le même couple de id secret/password, je le sais car je l’utilise dans un projet que je développe en ce moment.
Il y a une histoire de nonce dans l’algo ed25519 qui doit etre implémenté différemment selon les librairies
Les tests vérifient la signature, et ça ça fonctionne bien. Mais pas la génération d’un couple de clé a partir d’un couple id secret/pass wd, je te rajoute le test unitaire si tu veut mais ça va casser les tests
En fait je n’ai pas la solution, j’utilise directement la clé privée du couple que je veut utiliser que je récupère au format fichier de clé depuis duniter-ts
Ou plus exactement, je ne pense pas concevoir un outil suffisamment puissant pour ébranler la sécurité des algo de cryptographie modernes utilisé dans Duniter.
En revanche, pour un utilisateur qui à suffisement d’indice (ou de souvenir partiels) de ce que peuvent être ses identifiants secret et mot de passe, là oui, j’espère le rendre capable de tester suffisement de variante proche pour qu’il puisse retrouver celle qu’il a utilisé pour son compte.
Après, pour éviter que mon code ne fauche les identifiants retrouvé, je ne peux que me faire confiance (ce qui dans mon cas n’est pas difficile) mais pour les autres, je ne peux que recommander d’auditer le code, et d’en utiliser des instance installé en local ou héberger par des personnes de confiances.
Ce qu’on avait remarqué c’était qu’un même clé privée et un meme message ne donnait pas forcement la même signature, et c’est un problème connu. Mais le couple salt/pass c’est franchment bizarre, car ça retire tout l’interet d’avoir une méthode de génération standardisée.
@nanocryk bon je viens de regarder en fait bonne nouvelle c’est juste que tu avait inverser le password et le salt lors de l’appel de la crate de crypto
Pour l’instant, pas de worker ou accélérer, pas de génération de variante à partir de celles indiqué…
Gsper teste juste chacun des identifiants secrets listé avec chacun des mots de passe listés et regarde si le résultat correspond à la clef publique recherché.
