Have the same way to create and encode wallet between Thyra and Massa-client

[SebastienValla]

We changed the way to encode our thyra wallet to be iso with massa-client following this ticket : https://github.com/massalabs/thyra-plugin-wallet/issues/29 Please check the comments on the PR : https://github.com/massalabs/thyra-plugin-wallet/pull/30

We need to decide what we do for the salt length and for the file format (you use .dat we use json)

[AurelienFT]

I've answered you about the salt size on the other PR.

About the encoding json vs our proper. I don't know why it wasn't JSON at start I think only @damip is the last person remaining from this period.

[damip]

I've answered you about the salt size on the other PR.

About the encoding json vs our proper. I don't know why it wasn't JSON at start I think only @damip is the last person remaining from this period.

Nothing prevents from encoding the plaintexy contents as json, but the whole thing then needs to be encrypted, so either the encrypted version itself is encapsulated as string in a json (what would be the point ?), or just left as a binary (.dat)

[AurelienFT]

To add more precision (cc @SebastienValla) currently our dat file is a JSON object encrypted. The representation of the object when decrypted is :

{
   "Addr": {
       "secret_key": "xxx",
       "public_key": "xxx"
  },
  "Addr2": ...
}

[bilboquet]

(cc @SebastienValla ) Having read the discussion and both related issues in Thyra, I feel like I'm lacking some context. (I'm new to the subject). Can someone confirm that on core side we only need to change the size of the salt from 12 to 16 bytes? Side question: how to test with Thyra?

[SebastienValla]

@bilboquet we need to change the salt to 16 bytes and if possible have the following output file format (.json) { "version": 0, "nickname": "seb", "address": "A16eDqJHyZWQfhNq7xUbyqMMMjb1iKfqQy9p91uTCqY1xkUTC7k", "keyPairs": [ { "PrivateKey": "ZnS0859HSmkG1aFaF0+N8FAhPElYdbaxSD/KdwlH+Wwxh99J6ppjTBWFpaLCfCig9HM1UJX0Sz4eXrwVzHSe6X9SevCrBynKqn8qFprm3vI=", "PublicKey": "EtOWslwg46zJEPk/uLhGhMUs9V9N2mpWnPk0gmmWLsc=", "Salt": [ 239, 71, 191, 31, 141, 157, 166, 33, 146, 186, 49, 89, 188, 114, 207, 217 ], "Nonce": [209, 161, 110, 163, 92, 228, 4, 107, 238, 171, 113, 15], "Protected": true } ] } The goal is to have an unique generated file to be able to share files between client and thyra

[bilboquet]

@SebastienValla Thanks for the reply.

Let me explain the solution we are considering. (This, I hope, summarize whav @damip and @AurelienFT said above)

First, this issue seems to contains several points:

• the SALT length have to be common (we can forget about it, it's trivial we have already set it to 16bytes on our side),
• the need (I mean they are mandatory) for certain information to be present in clear in the file representing the wallet: aka the "salt" and the "nonce",
• the need to share some triplets (address, secret key, public key) in a secure way in the wallet: aka "ciphered-data",
• a common structure describing the deciphered "ciphered-data",
• a common structure describing the whole wallet file: aka wallet.json,
• a version field, because we always need a version.

when reading Any field that is not mandatory but present in the file should be silently ignore.

when writing Any field that is not mandatory should be avoided to prevent incompatibilities (one should consider to store them separately).

So here is the proposed format for the wallet.json (not fully json compliant, I hope you get my point): { "version": "Number", "salt": [ "array of 16 byte" ], "nonce": [ "array of 12 byte" ], "ciphered-data":"ciphered data value as string" }

And the format for the deciphered "ciphered-data":

{ "address 1 value": { "secret_key": "secret_key1 value", "public_key": "public_key1 value" }, "address 2 value": { "secret_key": "secret_key2 value", "public_key": "public_key2 value" }, "address 3 value": { "secret_key": "secret_key3 value", "public_key": "public_key3 value" } }

I have dropped some information from your example (mostly because I don't have them) and rearrange some other (mostly for the sake of security)

Please, let me know your thought about this.

[SebastienValla]

@SlnPons salt size is fixed, the files format between thyra and massa-client still diverge, it could be a not fast forward work to do on core side, which priority is it ?

[bilboquet]

Side notes: If I have understood correctly, on Thyra side:

• they'd like to have one wallet file per address.
• salt is different in each file

This will probably have an impact on core.

[bilboquet]

Based on my current understanding, I'd like to add some details on the use case.

Please correct me if I'm wrong.

It seems like we don't want full bidirectional compatibility between "wallet managers" (here wallet managers include massa-client and Thyra). That is because the main use case seems to be:

• a user create a wallet in massa-client (he wants to test, etc)
• then I want to migrate to a more versatile wallet manager (let's say Thyra), so he wants to import his wallet.

If this is really the use case, I think that the file format I propose above contains enough information.

On core side it's not that tricky, we basically have to carry the SALT and NONCE we're using, wrap the actual wallet.dat with them and generate a wallet.json.

Glad to hear your thoughts.

[bilboquet]

with a bit of variation in the format of the exported wallet (every field is an array of bytes) I have wallet.zip working.

in the attached zip you'll find

• an original wallet.dat (as usual)
• its content in clear in wallet.dat.clear.json
• an exported version with the salt and the nonce use in wallet.dat.json

[bilboquet]

Temporary version here https://github.com/massalabs/massa/tree/bilboquet/issue3444-share_wallet_format

[AurelienFT]

Final version to implement : https://github.com/massalabs/massa-standards/blob/main/wallet/file-format.md

[AurelienFT]

The standard only supports one keypair by file so we will need to have folders to keep maintaining the multi keys in wallet on client and staking. Is that a problem @damip ?

[damip]

The standard only supports one keypair by file so we will need to have folders to keep maintaining the multi keys in wallet on client and staking. Is that a problem @damip ?

I guess we could create a "wallets" folder and put all the wallet files inside

[AurelienFT]

I guess we could create a "wallets" folder and put all the wallet files inside

Yes will go for it then !