Gsper arriver à coder Gsper

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.

@cgeek @elois @nanocryk @kimamila

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

1 « J'aime »

Super, je pense que j’ai tout ce qu’il me faut avec le bout de code que tu viens de m’indiquer :slight_smile:

Plus qu’a faire quelque test et je vous tiens au courant si je coince quelquepart ou je pense que vous pouvez m’aider :wink:

1 « J'aime »

Bonjour @1000i100

Quel mécanisme envisage -tu pour garantir que les éventuels couples d’identifiant et phrase de passe retrouvé ne seront pas fuité ?

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 :confused:

1 « J'aime »

Ah… oui, tu fais bien de le préciser ! :slight_smile:
Du coup, si tu as des info pré-maché, je suis prenneur, sinon je fouille ça dès que j’ai un instant.

Serieux ?! Merde, je pensais avoir fait des tests pour ça. Un ticket de plus à ouvrir xD

1 « J'aime »

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 :stuck_out_tongue:

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 :wink:

Aucun.

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.

1 « J'aime »

@nanocryk hop c’est fait, j’ouvre l’issue et je push mon test :

---- keys::ed25519::tests::keypair_generate_ stdout ----
        thread 'keys::ed25519::tests::keypair_generate_' panicked at 'assertion failed: `(left == right)`
  left: `"Dy9QiniLiYprhzeuUna1qPrSGBDv1R7GHC5wYv1Eet1k"`,
 right: `"7iMV3b6j2hSj5WtrfchfvxivS9swN3opDgxudeHq64fb "`', crypto/keys/ed25519.rs:474:9
note: Run with `RUST_BACKTRACE=1` for a backtrace.

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.

Ha ok c’est pour ça que je ne te l’ai pas signalé car je pensais que tu avait déjà remarquer les deux (qui ont probablement la même cause)

@1000i100 en fait ton projet ressemble beaucoup a ce qu’a fait @jytou … (avec l’option -w)

4 « J'aime »

@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 :wink:

je viens de pousser un correctif :slight_smile:

2 « J'aime »

Hahaha je suis mauvais xD Je me disais aussi que ça n’avait pas de sens d’avoir des résultats différents à ce niveau là :stuck_out_tongue:

1 « J'aime »

Effectivement, ça ne fait pas exactement la même chose, mais ça s’en rapproche beaucoup !

Il y a des chances que sa version soit plus véloce que la mienne, mais moins user-friendly.

3 « J'aime »

V1 fonctionnelle !

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é.

Si oui, la combinaison gagnante est affichée.

C’est tout pour l’instant.

https://gsper.duniter.io/ =>

404 Not Found

c’est normal docteur ? Petit souci nginx ?

Normal… normal…
Presque :stuck_out_tongue:

(je déménage les outils de l’écosystème (qui ne sont donc pas des clients à proprement parlé) dans le groupe tools).

Du coup, il faut que je face la redirection qui va bien au niveau nginx en effet pour que tout ce passe bien :wink:

1 « J'aime »