# RFC DEWIF: Duniter Encrypted Wallet Import Format
**URL:** https://forum.duniter.org/t/rfc-dewif-duniter-encrypted-wallet-import-format/8222
**Category:** Protocols
**Tags:** dewif, mnemonic
**Created:** [21 March 2021 15:14 UTC](https://forum.duniter.org/t/rfc-dewif-duniter-encrypted-wallet-import-format/8222 "2021-03-21T15:14:22Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@elois](https://forum.duniter.org/u/elois)
#### Post date: [21 March 2021 15:14 UTC](https://forum.duniter.org/t/rfc-dewif-duniter-encrypted-wallet-import-format/8222/1 "2021-03-21T15:14:22Z")
Je commence à avoir beaucoup de RFC en attente : DEWIF, Dubp-Mnemonic, HD wallet.
HD wallet dépend de Dubp-Mnemonic qui dépend de DEWIF.
Je propose donc de merger en premier lieu la RFC DEWIF.
@Moul@vit@kimamila@poka , pouvez-vous la reviewer svp ? Merci 🙂
> **[rfc/0013\_Duniter\_Encrypted\_Wallet\_Import\_Format.md · master · documents / RFCs](https://git.duniter.org/documents/rfcs/blob/master/rfc/0013_Duniter_Encrypted_Wallet_Import_Format.md)**
>
> Documentation of the Duniter ecosystem. Provide protocol details, conventions and RFCs (Request For Comments).
---
### Author:  [@vit](https://forum.duniter.org/u/vit)
#### Post date: [21 March 2021 16:02 UTC](https://forum.duniter.org/t/rfc-dewif-duniter-encrypted-wallet-import-format/8222/2 "2021-03-21T16:02:40Z")
J’ai l’impression que la V3 et la V4 sont strictement identique en terme de spécifications. Seul la seed d’exemple et le type de clef publique dans la procédure de vérification semblent différentes…
---
### Author:  [@elois](https://forum.duniter.org/u/elois)
#### Post date: [21 March 2021 17:33 UTC](https://forum.duniter.org/t/rfc-dewif-duniter-encrypted-wallet-import-format/8222/3 "2021-03-21T17:33:22Z")
> [@vit](#):
>
> J’ai l’impression que la V3 et la V4 sont strictement identiques en termes de spécifications.
Et pourtant non pas du tout, elles sont carrément incompatibles :
> Version 4 stores an HD wallet according to the [BIP32-Ed25519](https://drive.google.com/file/d/0ByMtMw2hul0EMFJuNnZORDR2NDA/view) specifications.
Cela est dû au fait que l’algo BIP32-Ed25519 est différent de l’algo Ed25519, ils sont incompatibles entre eux.
Cela implique qu’une même seed donnera des clés publiques différentes selon qu’on utilise BIP32-Ed25519 où Ed25519.
Le préfixe d’un DEWIF (sa version), sert aussi à savoir quel est l’algo à utiliser. Ce qui sera très utile pour de futurs algos.
---
### Author:  [@elois](https://forum.duniter.org/u/elois)
#### Post date: [21 March 2021 17:42 UTC](https://forum.duniter.org/t/rfc-dewif-duniter-encrypted-wallet-import-format/8222/4 "2021-03-21T17:42:41Z")
@Moul j’ai traité tes retours. Je te laisse passer les remarques en résolu si c’est bon pour toi 🙂
---
### Author:  [@kimamila](https://forum.duniter.org/u/kimamila)
#### Post date: [22 March 2021 07:50 UTC](https://forum.duniter.org/t/rfc-dewif-duniter-encrypted-wallet-import-format/8222/5 "2021-03-22T07:50:02Z")
Ça a l’air bon pour moi. Beau travail !
J’avais juste une question sur le titre. A t-on besoin de préciser que c’est pour l’import ? Ça me semble superflu. C’est juste un format de clefs.
---
### Author:  [@vit](https://forum.duniter.org/u/vit)
#### Post date: [22 March 2021 08:35 UTC](https://forum.duniter.org/t/rfc-dewif-duniter-encrypted-wallet-import-format/8222/6 "2021-03-22T08:35:22Z")
Il y a encore des petits soucis de mise en page :
```
keypair seed: 0xbfa3f6e322cf21d0e652f79a69df9498fdf5347665e5646d9041f756496a1143 N : 4096
r: 16
p: 1
```
Pour plus de clarté sur les paramètres, je propose une liste avec les champs en gras :
- **keypair seed:** 0xbfa3f6e322cf21d0e652f79a69df9498fdf5347665e5646d9041f756496a1143
- **N:** 4096
- **r:** 16
- **p:** 1
---
### Author:  [@elois](https://forum.duniter.org/u/elois)
#### Post date: [22 March 2021 16:08 UTC](https://forum.duniter.org/t/rfc-dewif-duniter-encrypted-wallet-import-format/8222/7 "2021-03-22T16:08:10Z")
> [@kimamila](#):
>
> J’avais juste une question sur le titre. A t-on besoin de préciser que c’est pour l’import ? Ça me semble superflu. C’est juste un format de clefs.
C’est parce que par convention dans le domaine des crypto on parle de WIF (wallet Import Format).
C’est aussi parce que ce format sert à sérialiser un trousseau pour l’importer dans un autre logiciel, il ne sert donc qu’a l’import 🙂
On pourrait bien sur retirer le terme import, mais je préfère le garder car ça permettra aux profils techniques venant d’autres cryptos de comprendre plus rapidement de quoi il s’agit 😉
> [@vit](#):
>
> Il y a encore des petits soucis de mise en page :
Fixed 🙂
> [@vit](#):
>
> Pour plus de clarté sur les paramètres, je propose une liste avec les champs en gras :
C’est fait 🙂
---
### Author:  [@vit](https://forum.duniter.org/u/vit)
#### Post date: [22 March 2021 17:38 UTC](https://forum.duniter.org/t/rfc-dewif-duniter-encrypted-wallet-import-format/8222/8 "2021-03-22T17:38:29Z")
Pour les version 3 et 4, tu écris cette formule :
**N:** `2^(log N)`
Dans `(log N)`, `N` semble pas défini. Ou bien signifies-tu logarithme népérien, mais de quoi ?
C’est pas récursif j’espère, hein, sinon ça explose 😉 .
Peux-tu clarifier svp ?
---
### Author:  [@elois](https://forum.duniter.org/u/elois)
#### Post date: [22 March 2021 18:00 UTC](https://forum.duniter.org/t/rfc-dewif-duniter-encrypted-wallet-import-format/8222/9 "2021-03-22T18:00:32Z")
`log N` est le nom du champ qui stocke un u8 (entier non signé sur 8 bits).
`N` est le paramètre d’entrée de scrypt.
Dans le DEWIF on stocke le log2 de `N`.
---
### Author:  [@vit](https://forum.duniter.org/u/vit)
#### Post date: [22 March 2021 18:48 UTC](https://forum.duniter.org/t/rfc-dewif-duniter-encrypted-wallet-import-format/8222/10 "2021-03-22T18:48:55Z")
Pour la structure binaire de la `version` (4 octets) et de la `currency` (4 octets), quel endian doit-on utiliser , big ou little?
---
### Author:  [@elois](https://forum.duniter.org/u/elois)
#### Post date: [22 March 2021 19:01 UTC](https://forum.duniter.org/t/rfc-dewif-duniter-encrypted-wallet-import-format/8222/11 "2021-03-22T19:01:13Z")
> [@vit](#):
>
> quel endian doit-on utiliser , big ou little?
Le champ `currency` n’est pas un nombre, cette question n’a donc pas de sens pour ce champ.
Pour le champ version, l’information est effectivement manquante, c’est du big endian, je l’ajoute à la RFC 🙂
---
### Author:  [@vit](https://forum.duniter.org/u/vit)
#### Post date: [22 March 2021 19:04 UTC](https://forum.duniter.org/t/rfc-dewif-duniter-encrypted-wallet-import-format/8222/12 "2021-03-22T19:04:15Z")
Le `currency code` je voulais dire. Bref le champ stocké en binaire en 4 octets. Ce n’est pas une chaîne, il faut donc bien préciser le endian je pense.
---
### Author:  [@elois](https://forum.duniter.org/u/elois)
#### Post date: [22 March 2021 19:07 UTC](https://forum.duniter.org/t/rfc-dewif-duniter-encrypted-wallet-import-format/8222/13 "2021-03-22T19:07:02Z")
Il n’y a pas que les chaines et les nombres dans la vie, le `currency code` n’est ni l’un ni l’autre, c’est un tableau de 4 octets 😉
il y a déjà un tableau de correspondance entre chaque monnaie et son `currency code` (représentation hexadécimale des 4 octets comme le sous-entend le préfixe standard `0x`). On amendera ce tableau si de nouvelles monnaies basées sur Duniter sont lancées 🙂
---
### Author:  [@kimamila](https://forum.duniter.org/u/kimamila)
#### Post date: [23 March 2021 09:09 UTC](https://forum.duniter.org/t/rfc-dewif-duniter-encrypted-wallet-import-format/8222/14 "2021-03-23T09:09:04Z")
> [@elois](#):
>
> C’est parce que par convention dans le domaine des crypto on parle de WIF (wallet Import Format).
ok
> [@elois](#):
>
> C’est aussi parce que ce format sert à sérialiser un trousseau pour l’importer dans un autre logiciel, il ne sert donc qu’a l’import
Au début de la spec, il est écrit que le format de sérialisation n’est pas géré par cette spec.
On ne sait donc pas si c’est une fichier, son extension, etc.
Par exemple, on pourrait sérialiser en fichier `.dunikey`, avec un `Type: "DEWIF"` ?
Pour les utilisateurs lambda, non habitué aux cryptos, une extension de fichier en `.dewif` ne pas parait pas parlante du tout…
Autre remarque que j’ai sur le format : on parle de `version`, mais chaque version correspond à des fonctionnalités différentes. Je trouveras plus explicite d’avoir un terme du style `type`.
Par exemple, souvent les veilles versions ne sont plus implémentée, car devenues obsolètes. Mais il semble que cette RFC indique de gérer toutes les `versions` : ca parait incohérent.
---
### Author:  [@vit](https://forum.duniter.org/u/vit)
#### Post date: [23 March 2021 09:11 UTC](https://forum.duniter.org/t/rfc-dewif-duniter-encrypted-wallet-import-format/8222/15 "2021-03-23T09:11:54Z")
C’est bon, je stocke correctement le tableau du code de la monnaie.
Dans la RFC, les numéros d’exemples ont un dièse devant, ce qui fait que Gitlab les transforme en un lien vers un ticket à ce numéro. Il faut enlever le dièse ou l’échapper.
Example [#2](https://forum.duniter.org/documents/rfcs/-/issues/2):
J’ai fini le support de la v1. Pour la v3 j’ai un problème, scrypt n’ accepte pas les paramètres donnés :
**N:** 32768
**r:** 16
**p:** 1
**dklen** : 32
```
ValueError: Invalid parameter combination for n, r, p, maxmem.
```
[edit]
C’est un bug connu sur cette implémentation Python :
>
>
> But 2\*\*14 still works.
> This is only in a recent version I think.
> Note that 2\*\*20 is still a possible value in the...
Un problème de la valeur de mémoire max pas assez grande par défaut.
---
### Author:  [@elois](https://forum.duniter.org/u/elois)
#### Post date: [23 March 2021 17:50 UTC](https://forum.duniter.org/t/rfc-dewif-duniter-encrypted-wallet-import-format/8222/16 "2021-03-23T17:50:41Z")
> [@kimamila](#):
>
> Au début de la spec, il est écrit que le format de sérialisation n’est pas géré par cette spec.
Au contraire, c’est bien un format de sérialisation, mais pas un format de fichier. C’est une chaîne de caractères base64, que tu la stockes tel quelle ou parmi d’autres données la RFc est agnortique là-dessus 🙂
> [@kimamila](#):
>
> Par exemple, on pourrait sérialiser en fichier `.dunikey`, avec un `Type: "DEWIF"` ?
> Pour les utilisateurs lambda, non habitué aux cryptos, une extension de fichier en `.dewif` ne pas parait pas parlante du tout…
Ce n’est pas un format de fichier donc pas une extension, donc cette question est en dehors du scope de cette RFC.
Cette question porte sur la définition d’un format de fichier commun dont on parle ici : [Carnets d'adresses / HD wallets partagés entre clients - #7](https://forum.duniter.org/t/carnets-dadresses-hd-wallets-partages-entre-clients/8219/7)
> [@vit](#):
>
> Dans la RFC, les numéros d’exemples ont un dièse devant, ce qui fait que Gitlab les transforme en un lien vers un ticket à ce numéro. Il faut enlever le dièse ou l’échapper.
>
> Example [#2](https://forum.duniter.org/documents/rfcs/-/issues/2):
Ok je viens de supprimer les #
> [@vit](#):
>
> C’est un bug connu sur cette implémentation Python :
Dans ce cas si tu veux supporter la v3 (et la v4) ce serait bien de choisir une implémentation de scrypt qui supporte des plus grosses valeurs de N 🙂
---
### Author:  [@vit](https://forum.duniter.org/u/vit)
#### Post date: [24 March 2021 08:56 UTC](https://forum.duniter.org/t/rfc-dewif-duniter-encrypted-wallet-import-format/8222/17 "2021-03-24T08:56:01Z")
Je suis d’accord avec @kimamila sur la confusion entre version et type de structure/contenu de la sérialisation.
Je propose ceci pour simplifier la RFC et les implémentations :
- C’est la première version de la RFC, alors on ne doit avoir que la version 1. Cela me paraît plus logique.
- Pour les variantes, on ajoute un champ `type`, avec un code (chaîne, entier, ou tableau parce que y a pas que les chaînes ou les entiers dans la vie, y a aussi les tableaux). Pour moi un entier suffit.
- Du coup en suivant ce raisonnement, dans `version` on met 1.
- La variante 3 est une évolution de la variante 1, on peut donc supprimer la variante 1, car elle peut être stockée sous la forme de la variante 3.
- La variante 2, stockage de plusieurs trousseaux, pareil, elle peut stocker 1 clef, donc on vire la variante 3 et 4, et on spécifie le type (ed25519 ou bip32-ed25519) avec le champ `type`.
Au final, on devrait avoir dans la RFC de la `version 1` de la sérialisation :
- La version 2 actuelle avec 1 dans le champ version, déclinée en deux types : (ed25519 ou bip32-ed25519)
## Dewif bytes structure
| Version | Currency code | Type | log N | Version data |
| --- | --- | --- | --- | --- |
| 4 bytes big endian | 4 bytes | 1 byte | 1 byte | Any size |
## Currencies code
| Currency | Code |
| --- | --- |
| None | 0x00000000 |
| Ğ1 | 0x00000001 |
| Ğ1-Test | 0x10000001 |
## Type code
| Type | Code |
| --- | --- |
| ed25519 | 0x01 |
| bip32-ed25519 | 0x02 |
## Version data (encrypted)
| seed1 | public key1 | seed n… | public key n… |
| --- | --- | --- | --- |
| 32 bytes | 32 bytes | 32 bytes | 32 bytes |
The public key serves as a checksum. To check that the DEWIF base64 string is not corrupted, simply generate an ed25519 keypair with the seed and check that the obtained public key matches.
Symmetric encryption algorithm : aes256
aes256 key: scrypt of user passphrase with the following parameters:
**password:** passphrase
**salt:** sha256(« dewif » ++ passphrase)
**N:** `2^(log N)`
**r:** 16
**p:** 1
---
### Author:  [@elois](https://forum.duniter.org/u/elois)
#### Post date: [24 March 2021 19:29 UTC](https://forum.duniter.org/t/rfc-dewif-duniter-encrypted-wallet-import-format/8222/18 "2021-03-24T19:29:49Z")
@kimamila@vit suite a vos remarques je viens de retravailler entièrement la RFC:
Il n’a plus qu’une seule version, qui contient comme méta-données l’algorithme et le `Log N`.
Pour simplifier également, un DEWIF ne stockera qu’un seul trousseau.
Avec les HD wallet on peut générer une infinité de trousseaux à partir d’un seul trousseau maître, et celui qui à plusieurs trousseaux maîtres peut avoir un DEWIF pour chaque trousseau maître, ça me semble plus cohérent.
J’ai ajouté 2 exemples (1 par algo):
> **[rfc/0013\_Duniter\_Encrypted\_Wallet\_Import\_Format.md · dewif · documents / RFCs](https://git.duniter.org/documents/rfcs/blob/dewif/rfc/0013_Duniter_Encrypted_Wallet_Import_Format.md)**
>
> Documentation of the Duniter ecosystem. Provide protocol details, conventions and RFCs (Request For Comments).
---
### Author:  [@vit](https://forum.duniter.org/u/vit)
#### Post date: [27 March 2021 09:42 UTC](https://forum.duniter.org/t/rfc-dewif-duniter-encrypted-wallet-import-format/8222/19 "2021-03-27T09:42:22Z")
J’ai ajouté un commit pour corriger des petits bugs de markdown, et j’en ai profité pour mettre les paramètres dans des tableaux. @elois, ne force push pas sur la branche 😉
C’est bon pour moi.
---
### Author:  [@elois](https://forum.duniter.org/u/elois)
#### Post date: [27 March 2021 12:33 UTC](https://forum.duniter.org/t/rfc-dewif-duniter-encrypted-wallet-import-format/8222/20 "2021-03-27T12:33:28Z")
> [@vit](#):
>
> @elois, ne force push pas sur la branche
C’est noté je viens d’update ma branche locale 🙂
[Next page](https://forum.duniter.org/t/rfc-dewif-duniter-encrypted-wallet-import-format/8222.md?page=2)