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