Définir un format sécurisé pour les trousseaux de clés Ğ1

[elois]

@Moul

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.

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.

@Moul

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

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.

@Moul

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 ?

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 :

• Soit c’est pour des tests => alors pas besoin de le stocker dans un fichier, il peut changer a chaque test.
• Soit c’est pour le trousseau réseau du nœud => alors il sert de certificat, c’est la seule façon de s’assurer que l’on communique bien avec le nœud avec lequel on croie communiquer, ce trousseau doit être chiffré.

@Moul

Est-ce qu’il est possible de l’imposer ?

oui

@Moul

Est-ce judicieux de l’imposer ?

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 :

• Un standard permissif, dont l’utilisation n’est pas recommandée, mais l’utilisateur reste libre de prendre des risques sur les applications qui acceptent ce standard permissif (il convient d’alerter explicitement l’utilisateur du risque qu’il encourt, ce qui n’est pas le cas aujourd’hui).
• Un standard sécurité (format DEWIF), qui sera recommandé dans les recommandations de sécurité officielles, et qui sera le seul format accepté par Dunitrust.

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.