Est standard ce qui a été validé par la théorie et surtout par l’expérience, et pas seulement la théorie. Les usages sont importants.
Je t’ai dit que pour ma part j’implementerai ce nouveau format dans Cesium. Voudrais tu que je supprime en plus les autres formats disponibles ?
Ne prends pas la mouche, s’il te plait.
Ce nouveau format subira des MR, des évolutions, etc. Et ensuite chacun verra s’il doit en faire la promotion, comme plus sécurisé ou non. Les plus utilisés et mis en avant par les developpeurs deviendront des standards de fait.
Par exemple, @tuxmain n’a pas cherché à dire que son protocole d’anonymisation était le standard. Il l’a d’abord fait, décrit, puis présenté, etc. On verra s’il devient le standard, s’il résiste aux critiques de ceux qui s’y intéresseront. Cela peut être long. C’est tout un processus, qui ne dépend pas uniquement de la volonté de ceux qui réalise le prototype et les specs.
Je trouve ça fort dommage qu’un standard doivent autoriser le stockage du trousseau de clés en clair 
Car si on l’autorise, l’utilisateur ayant tendance a vouloir aller au plus simple, il ne chiffrera pas son trousseau de clés.
Quel sont selon toi les usages qui nécessiteraient de stocker le trousseau de clés en clair ?
Si on part sur un format qui le permet, comment faire en sorte que l’utilisateur soit poussé a chiffre son trousseau de clés par défaut ?
Par format “standard” j’entends format recommandé. Peut-être que le mots clés “standard” est mal choisi de ma part. Je souhaite surtout que le format recommandé officiellement soit un format chiffré.
Il y a un principe fondamental en sécurité: la configuration par défaut doit apporter une sécurité satisfaisante, car 95% des utilisateurs utilisent la configuration par défaut.
Non, bien sûr que non 
Ma crainte est que “les plus utilisés et mis en avant par les développeurs” ne correspondent pas forcément aux formats satisfaisant en terme de sécurité mais au format préférés par les développeurs pour d’autres raisons.
Oui tout a fait
Bon la 1ère version “finalisée” des spec est là : rfc/0013_Duniter_Encrypted_Wallet_Import_Format.md · dewif · nodes / common / doc · GitLab
N’hésitez pas, si vous avez des remarques constructives
J’ai déjà codé une implémentation de référence en Rust, que je vais partager dans un autre fils.
L’implémentation de référence du format DEWIF se trouve dans la bibliothèque dup-crypto-rs.
Documentation : https://docs.rs/dup-crypto/0.12.0/dup_crypto/dewif/index.html#handle-dewif-format
Code : https://git.duniter.org/libs/dup-crypto-rs/-/tree/dev/src/dewif
Des tests sur la Ğ1-test. J’ai pas envie de déchiffrer mes fichiers d’authentification à chaque test. Je m’en fous un peu que matograine me vole mes Ğ1-test si je commite par erreur mon authfile. Les fichiers d’authentifications non chiffrés remplissent bien ce rôle.
Ça peut également être le cas pour les portefeuilles Ğ1. Si j’ai pas envie de chiffrer mon authfile pour pouvoir dépenser sans me prendre la tête mes Ğ1 lors d’une rencontre physique. Le risque que je prends et de les perdre. C’est un risque à prendre, mais ça serait dommage d’être imposé d’utiliser le chiffrement pour une petite somme.
Ce qui pourrait être fait, c’est que le client, à la création de l’authfile, propose (ou impose (refuse de le générer)) un format chiffré pour une clé membre ou un portefeuille avec beaucoup d’unités. Au cas contraire, un authfile non chiffré est bienvenue.
Ben, le format de fichier que tu proposes est bien pour cela au même titre que EWIF. Mais imposer son usage c’est trop. On dirait que tu n’as pas vu l’usage client ou du moins que tu t’occupes du côté client sans avoir trop mis les mains dans le cambouis. Même d’un point de vue nœud, je m’en fous d’avoir un format chiffré pour une clé générée aléatoirement. Aurai-je besoin de déchiffrer ma clé générée aléatoirement au redémarrage ?
C’est la contrainte que tu t’es imposée avec ce format de fichier. Est-ce qu’il est possible de l’imposer ? Est-ce judicieux de l’imposer ? Est-ce qu’imposer aux autres sa définition de bien est toujours bien pour l’autre ?
Sinon, il y a déjà PubSec, WIF. Tu peux proposer deux formats de fichier d’authentification : un chiffré et un non chiffré. Comme pour WIF et EWIF. Avec les apports qu’apportent tes fichiers sur ces derniers.
Pour les tests il me semble avoir abordé plus haut la génération de trousseaux aléatoires a chaque démarrage. En fait je pense qu’il y a beaucoup de cas d’usages ou l’on a pas besoin de stocker le trousseau de clés dans un fichier.
Mouais, perso ça me choque pas de rentrer mes crédentials pour payer, même un epetite somme.
En fait l’idéal serait d’avoir un client permettant d"éméttre plusieurs transactions et de les signer toutes d’un coup en différé.
Par exemple lors d’un gmarché, je fais mes paiements, les documents transactions restent en local sur ma machine. Et quand j’ai fini mes emplettes, je rentre mes credentials une seule fois et mon client va alors signer et envoyer toutes les transactions qu’il a prégénéré pendant mes emplettes, ça ce serait pratique et secure.
Ce n’est pas mon avis, mais c’est notamment parce que je compte me baser sur la clé publique du nœud pour authentifier le réseau pkstl. Avec cette approche, l’utilisateur indique la clé publique du nœud de confiance auquel il se synchronise, si cette clé est corrompue, alors il peut tomber sur un nœud menteur, on ne peut alors plus avoir confiance en le réseau.
Et je parle bien du trousseau réseau généré aléatoirement, pas de trousseau membre ici.
Si le trousseau est généré aléatoirement :
oui
Dans le cas du logiciel Dunitrust je pense que oui
Pour les autres logiciels j’entends que ce n’est pas souhaité.
Du coup j’ai changé d’approche et renommé le titre de ce fils.
Je pense qu’on se dirige vers 2 formats “standards” différents :
Concernant le standard permissif, je vous laisse faire le boulot de standardisation (qui me semble souhaitable pour éviter les problèmes des formats “conteneurs”). Le temps étant une ressource trop limitée, je me concentre sur ce qui est prioritaire pour moi.
Désolé par avance pour la mauvaise blague.
Je sais que ça a été compris et je ne doute pas des choix techniques faits par l’outil utilisé et par son usage.
Juste envie de rigoler un peu sur la résultante de ce post :
Heureusement l’auto-dérision ça me connaît 
Il est bon de savoir rire de soit même dans la vie 
Without any intention of reopening this can-of-worms, and disclosing that « I know just enough to be dangerous. »… my thoughts and questions below.
I’ll side toward the opinion « We should never save-to-disk unencrypted private key material » and I’ll add the nuance « without the end-user being warned and actively going out-of-their-way to do so. »
I know Im dangerously sloppy: Ive been working from the unverified assumption (because I saw the pattern right away) that an ed25519 private key contains its seed in the first 32 bytes. Q1) Is this really an unsafe assumption? If it’s ok… Im thinking that the statement « ring cannot work with a private key… it needs a seed » might not be the case.
my attempt to answer this question myself and break my assumption is assert_privkey32_is_seed.py.txt (1,3 Ko) … admittedly so that I could remain lazy and avoid digging into https://ed25519.cr.yp.to/ed25519-20110926.pdf and it’s references.
Q2) Is there a resolution to a single keychain format that all tools can use? Im liking dewif but I see it’s still a draft… and doesnt matter that I like it if other tools have not also implemented dewif.
Thank you for your time.
Spencer971
[added]
p.s. Please please please, do NOT waste your time answering my 1st question… I was simply poking around to see if anyone can quickly break my assumption without wasting their time researching. Im sloppy, and I’m not working on production code… I know a brute-force attempt to break my assumption is NOT good enough. I would never want anyone implementing my sloppy assumption without finding expert documented verification in a well peer-reviewed specification document; and I’ll continue looking for this myself. The very last reason Im here is to cause more work for others.
p.p.s: a faster brute-force that avoids scrypt is assert_privkey32_is_seed_noscrypt.py.txt (1,4 Ko)
I could try either to make Python bindings to the Rust DEWIF functions, either to write it natively in Python, so it can be used easily in natools, duniterpy, silkaj, sakia, etc.
Cool!
For academic/learning reasons, Ill also try to implement dewif in python (with my usual preference toward readability) while this topic is on my mind.
-Spencer971
[added]
Working from https://git.duniter.org/nodes/common/doc/blob/dewif/rfc/0013_Duniter_Encrypted_Wallet_Import_Format.md I’ve tried to implement v1 in python (since there is test data to work with), but I suspect this draft needs more work. I would feel HONORED to help out in this regard, if I can. First, perhaps @elois would want to take a look at my notes in this python script. dewif_draft.py.txt (1,4 Ko) I’m in no rush… I’ll move along for now and make myself available when devs have time to look at this.
-Spencer971
Les données de l’exemple 1 n’étaient pas à jour, le viens de les corrigées. Aussi le code pour la monnaie g1-test n’était pas le bon (décalage de 1 bit), c’est corrigé également
J’ai découvert aujourd’hui une erreur dans mon implémentation de DEWIF,
C’est dans la définition du salt que je me suis emellé les pinceaux : les spec disent :
salt=SHA256("dewif"++password)
Et j’avais implémenté : salt="dewif"+SHA256(password)
je viens de publier un hotfix :
@Spencer, maybe that’s why you had a gap?
Can you try again with the updated v1 example? And share your code? Thanks 
Hi Elois,
After my last post on Nov 13th above, I had not worked on this any further because I couldn’t see updated docs. The script that I left in that post DOES produce the same base64 dewif target that I was trying to match against the documentation. I never even got to hashing concatenated ‹ dewif › + password to create the aes key because lower in the documentation there was a hint of using 32 bytes of x00 (I thought: « why even encrypt? ») but tried anyways and was able to arrive at the target dewif string.
If you have updated docs with updated example data… I can restart from the docs and see if I arrive at the same encrypted data. The docs that I see are still a 9mo old draft… with sample seed/pubkey switched and a strange g1-test byte with 1 bit out of place.
Spencer971
I was going to try to read your latest changes, and play with my script to see if I could generate the same encrypted dewif string… but I failed miserably. Im sorry Elois, Im lost at this point.
-Spencer971
Yes I updated the RFC in the night
Too bad, can you share the latest version of your code with me so I can see what’s wrong?
I hate to waste your time because Im sure Im doing something dumb. Im still looking for updated docs but the link Im using is under /nodes/common/doc/blob/dewif/rfc/.
This morning’s code changes are few, a change from 1byte currency g1 to 4bytes g1-test, trying to match the dewif string in your latest dewif.rs commit, and using aes_pw=‘titi tata toto’ as scrypt passphrase and the hash of ‘dewif’ + aes_pw as salt to create the aes key.
If you point me to your latest docs link… I’d rather waste my time than yours.
dewif_draft.py.txt (1,7 Ko)
Spencer971
Haaa ok that’s why you can’t do it, you rely on the old repository that is archived. The RFC repository has been moved here: documents / RFCs · GitLab
The DEWIF RFC is here: https://git.duniter.org/documents/rfcs/blob/dewif/rfc/0013_Duniter_Encrypted_Wallet_Import_Format.md
