AEX-3 - Secure Storage format

Sophia Smart Contract Development AEXpansion Proposals
1

Hello All, this is the discussion topic for the AEX-3 Proposal:

2

It will be great to have this standardized so that one can export his keys from one piece of software and import them into another without much hassle.

Currently, the waellet browser extension is using this format, but I’ve had to implement it separately.

Does this proposal have the intention to have this in the SDK via its keystore?

Here’s an example of a secure key pair generated with waellet:

{  
   "name":"keystore",
   "version":1,
   "public_key":"PUBLIC_KEY",
   "id":"0dbaf81f-ee71-4c31-8c0a-a2863e18d854",
   "crypto":{  
      "secret_type":"ed25519",
      "symmetric_alg":"xsalsa20-poly1305",
      "ciphertext":"a90751d37ea7e1d0f9d314d6f98a26b24e5ab9b92c79a4a9cf7fe69c8edc63ce3bada02b4ae44255d3a0096c98ffd8c3875f7a3f9a76cb8d4917a1238aea99f0da8c451952c8e149f1077026f3fae002",
      "cipher_params":{  
         "nonce":"1fc43bcd7dcb14d4fd5639c78fed9d07368cca6db4182e6c"
      },
      "kdf":"argon2id",
      "kdf_params":{  
         "memlimit_kib":65536,
         "opslimit":3,
         "parallelism":1,
         "salt":"SOME_SALT"
      }
   }
}
3

this is already used by aeternity and is present in the SDK and that is the reason we chose to mark this under Informational type. :smiley:

1 Like
4

Cool I had a problem using this in the browser extension

When importing

import { dump } from '@aeternity/aepp-sdk/es/utils/keystore'

I get this:

ERROR in ../node_modules/bindings/bindings.js
Module not found: Error: Can't resolve 'fs' in '/Users/milenradkov/git/hack/waellet/mradkov/waellet/node_modules/bindings'
 @ ../node_modules/bindings/bindings.js 5:9-22
 @ ../node_modules/argon2/argon2.js
 @ ../node_modules/@aeternity/aepp-sdk/es/utils/keystore.js
 @ ./popup/utils/address-generator.js
 @ ../node_modules/babel-loader/lib!../node_modules/vue-loader/lib??vue-loader-options!./popup/router/pages/Index.vue?vue&type=script&lang=js&
 @ ./popup/router/pages/Index.vue?vue&type=script&lang=js&
 @ ./popup/router/pages/Index.vue
 @ ./popup/router/routes.js
 @ ./popup/router/index.js
 @ ./popup/popup.js

But it seems it’s only related to webpack. So I implemented this separately here. And also I thought this was not fully functional in the sdk yet as @nduchak.chain mentioned here in the forum a few days ago.

5

okay. maybe @nduchak.chain will share the status once it is available and working.
So to answer your original question, yes this will be/is part of the SDK.

2 Likes
6

@bruteforce.chain Hey,
Nice job. I will use your staff to fix keystore in sdk.
:trophy:

1 Like
7

:smiley: Cool! I’m glad I was able to help.

Hoping to see this implemented in the sdk soon. So I can get rid of the way I’m using it and use it via the sdk.

1 Like
8

moving aex-3 to review: Updates to aex-3 by shekhar-shubhendu · Pull Request #16 · aeternity/AEXs · GitHub

9

After feedback from @davidyuk, I’m planning to add a section on secret_type

### Secret types

Specifying an appropriate `secret_type` helps consumers to decide the proper way
of handling the decrypted data without having to store additional metadata.

The following `secret_type` values have been proposed:

- `ed25519-bip39-mnemonic`
- `ed25519-slip0010-masterkey`

This list should be expanded with adoption.

It is not advised to use this format as a store for arbitrary binary data.

In addition, I want to add an optional field secret_format

  - (optional) `secret_format` specifies the format of the encrypted data,
    if not specified then a consumer should assume raw bytes
10

AEX-3 has been in Review for a while now. I will move it into Last call (2019-11-14 to 2019-11-21). Please get any last comments in.

5 Likes
11

Looks like three is consensus for this, and can be safely set as final

1 Like