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

Oui, mais c’est pas directement la clée privé. Elle est transformée.

Dans le cas de Duniter c’est directement la clé privée encodée au format basee58, on peut considérer que c’est une “transformation”, mais ça ne résout pas mon problème, je ne peut pas m’en servir, il me faut la seed (ou les credentials).

Rappels sur la génération des trousseaux de clés Ğ1 :

(salt, password) → seed (32bytes) → secret key (64 bytes) → public key (32 bytes)

Chaque flèche représente une opération a sens unique, il est impossible de revenir en arrière. Nottament, il est impossible de retrouver la seed a partir de la clé privée car l’opération de génération de la clé privée a partir de la seed fait intervenir des fonctions a sens unique (sha512 notamment).

Je ne penses pas non. Je n’ai inventé aucun format, et repris tous ceux que j’avais trouvé à l’époque : ceux de gannonce et Duniter (PubSeb), ceux des wallets paper. La doc doit etre quelque part, sur le forum.
@cgeek nous avais proposé d’uniformiser, en ajoutant un Type: <PubSec|EWIF|WIF> etc.

Le format de Silkaj n’est arrivé qu’ensuite, je n’ai pas regardé de ce côté là.

Je peux ajouter sans problème le PubSeed dans Cesium. De préférence avec une ligne (qui peut-etre optionnel) Type: PubSeed.
Nous avions aussi parler d’une extension de fichier commune (pour un fichier ayant le Type: )

A vous lire…

En quoi exposer la seed par inadvertance est-il plus sécurisé ? Édit - ok, la seed est chiffrée et c’est le programme qui gère le déchiffrement.

Mais du coup, la clef de déchiffrement doit bien être stockée qq part dans certains cas, non ? Les séparer évite des fuites involontaires ?

Que représente le champs count ?

1 Like

Le nombre de trousseau dans le fichier. Mais je suis pas fan du format que ce count induit. Ca fait usine à gaz.

Je comprend bien mais j’ai dit cela car “le” format PubSec semble être implémenté différemment dans Cesium : Format des fichiers de trousseaux de clés .

De toute façon qu’importe, le format PubSec ne conviens pas pour plusieurs raisons exposées sur le 1er post (que je viens de mettre à jours).

Le format WIF défini par Tortue est de loin le plus intéressant : https://tmp.tednet.fr/paperwallet/AddressFormat.html

Il y a moyen de se servir de l’identifier pour versionner et étendre le format :slight_smile:

La seed n’est manipulée que pour générer le trousseau de clés, donc sur un très petit scope de la vie du programme, seulement au début.
La clé privée est manipulée tout le long de la vie du programme, car elle vas servir a chaque fois que le programme a besoin de générer une signature, elle est donc beaucoup plus utilisée que la seed, le risque de la faire fuitée est donc bien plus grand.
D’ailleurs, dans Duniter la fuite de la seed ne s’est jamais produite, alors que la fuite de la clé privée si, en en prod (la G1 était déjà lancée).

Non. Elle ne doit être stockée nul part autre que dans le cerveau de l’utilisateur et éventuellement son gestionnaire de mots de passe.

Il indique le nombre de trousseaux présents, ce n’est qu’une proposition, à discuter :slight_smile:

2 Likes

En tout les cas j’en ai besoin dans Dunitrust car je souhaite allier sécurité et simplicité d’usage, donc je ne génèrerai et n’accepterai que des formats chiffrés, or Dunitrust à deux trousseaux de clés (network et membre), donc je doit utiliser un format permettant de stocker plusieurs trousseaux.

Avoir 2 fichiers est incompatible avec la simplicité d’usage, je veut que l’utilisateur de Dunitrust n’ai qu’une seule passphrase a saisir au démarrage (donc un seul fichier a déchiffrer).

Vois tu une façon plus “légère” de stocker plusieurs trousseaux dans un même fichier ? :slight_smile:

2 Likes

Pour info, le WIF et sa version chiffrée le EWIF sont déjà supportés par DuniterPy et Cesium.

4 Likes

Duniter stocke la clef privée en clair sur le disque dur par défaut. Dunitrust devra bien stocker la speed, sauf s’ il demande les credentials ou la clef de déchiffrement à chaque redémarrage. Dunitrust ne pourrait donc pas être redémarré automatiquement et participer de suite au calcul ?

1 Like

Oui Dunitrust ne pourra pas être redémarrer automatiquement, et ce n’est pas un besoin.
Le fait que Duniter est besoin d’être redémarré régulièrement est lié à 2 problématiques spécifiques à Duniter :

  • fuites mémoires (ce qui cause le crash sur 2Go de RAM au bout d’un certain temps)
  • mauvais élagage des powcluster (problème qui sera normalement résolu en passant à node10)

Je ne vois pas le rapport. Duniter n’a pas besoin de redémarrer pour participer au calcul, ce sera pareil pour Dunitrust.

4 Likes

Je suis ravi que cette discussion sur la recherche de cohérence “inter-cryptographique” se prolonge.

Résumons les outils dont nous disposons :

  • symétrique: DATA <–(KEY)–> DATA*

    • avantage: symétrique, rapide …
    • inconvénient: partage “physique” de KEY

    Analogie: UN Coffre avec UNE Clef.

  • asymétrique:

    • DATA >–(PUB)–> DATA** >–(PRIV)–> DATA (chiffrage)
    • DATA >–(PRIV)–> DATA*** >–(PUB)–> DATA (signature)
      • avantage: permet Chiffrage ET Signature de message
      • inconvénient: mathématiques complexes

    Analogie: Courrier en “recommandé avec accusé de réception” en mieux.
    Avec le texte écrit à l’intérieur de l’enveloppe et qui se détruit si ce n’est pas le destinataire qui ouvre…

  • hashage qui permet de créer une “emprunte digitale”: DATA ----> DATA

Toute la sécurité informatique découle de ces propriétés mathématiques!

Pour se protéger d’eux même les ordinateurs en constante évolution augmentent la longueur de KEY ou complexifie l’espace mathématique de relation entre PUB/PRIV. Enfin, chaque espace mathématique définit “l’espace” d’empreinte du HASH (sa quantité de possibilités avant de boucler sur lui-même).

Le problème typique de l’Oeuf et de la Poule", résolu par l’emboîtement des poules ou des oeufs :wink:

N’oublions pas que nous faisons cela pour nous, les Humains!!
Et qu’il faut que nous soyons propriétaire et conscient de l’être de NOTRE CLEF

La clef qui chiffre nos comptes concerne notre souveraineté monétaire! Il me semble qu’elle est la plus importante… Et que nous devons pensez à sa sécurité, mais aussi à sa transmission…

“LA CLEF” doit être compréhensible par un Humain (diceware, mnemonic) et pouvoir se déléguer à d’autres sans danger https://darkcrystal.pw/

3 Likes

Les format WIF/EWIT définies par @Tortue sont binaires. DuniterPy et Cesium supportent t’il un fichier binarie contenant directement les octets ? Ou demandent t’il un fichier texte qui contient les octets encodées en base16 ou 64 ? @kimamila @vit ?

@Frederic_Renault pour l’instant l’objectif de définir un format standard pour les trousseaux de clés Ğ1, donc a priori ça ne concerne pas les clés symétriques. Mais on peut essayer de les inclurent si c’est on besoin,a tu un cas d’usage à nous donner ?

DuniterPy supporte uniquement le format fichier texte, mais derrière décode les octets. C’est trivial de lui faire avaler un fichier binaire si besoin. Mais peu importe. Ton souhait est de ne stocker que la seed, ce qui est le cas en WIF.

Le besoin de Rust est donc déjà résolu avec le format WIF/EWIF.

2 Likes

Dis donc, on a eu une tortue ninja avant-gardiste.

Pas actuellement non. Je pense étendre le format WIF/EWIF (avec un identifier 0x03) pour permettre le stockage de plusieurs trousseaux :slight_smile:

les octets sont encodé en quelle base du coup ? 16 ? 58 ? 64 ? autre ? Faudra que je le précise dans la spec du format.

1 Like

Le mieux serait de faire une RFC avec les formats utilisés actuellement dans Cesium/DuniterPy/Silkaj.

Je peux le faire si vous voulez.

3 Likes

Non, le format simple PubSec est bien implémenté. La il y avait un bug quelconque (le sablier d’attente, encore lui !) suite à l’ajout des portefeuilles secondaires.
C’est juste que ce format est aussi lisible par Cesium en format complet (avec Type: et version).
@Matograine monte souvent vite au créneau, sans analyse du code.

Oui, peu importe pour Cesium. L’idée importante pour moi est d’avoir une entête cohérente :

Type: <PubSec|WIF|EWIF|PubSeed|etc.>
Version: 1
...champs en fonction du format

et un point d’extension assiocié (.dunikey.yml ou autre).

2 Likes

Oui :smiley:

Oui ça m’aiderait beaucoup, et je pense que ça en aidera d’autres :slight_smile:

2 Likes

Il y a aussi l’outil de @1000i100 : DuniterkeyMaker

3 Likes