Use ethereum's web3 secret storage as the file storage format

[ethanfrey]

Would be especially good to meet ethereum's key standard: https://github.com/ethereum/wiki/wiki/Web3-Secret-Storage-Definition

Frey's comments on this:

Took a look into the ethereum "standard" and find it a bit confusing. Maybe you can explain:

Where is the source code for their implementation? No luck finding it with google. Ideally it would be a compatible license, so we could use it, but at least something to test against more that the two cases in the wiki. Even the likely areas of the codebase are misses: https://github.com/ethereum/go-ethereum/tree/master/crypto/

Pbkdf2 seems obsolete - better bcrypt (or scrypt): https://medium.com/@mpreziuso/password-hashing-pbkdf2-scrypt-bcrypt-1ef4bb9c19b3 among other sources. So why is this the main use case?

There also seems to be some internal discussion about security of these keys: https://github.com/ethereum/wiki/wiki/Brain-Wallet

Researching the ethereum aspects, and noting that we cannot use any code from them (due to GPLv3 vs. Apache licenses), I don't see any advantages to copying their format. Does anyone else use it? I mean ssh has another format to store password-protected private keys which seems more widespread. As does PGP. I don't understand what is so special about ethereum compatibility, but please explain what I am missing.

By researching their format, I did, however, come to the conclusion that scrypt is even better than bcrypt for storing secrets.

Bucky's answer:

believe its here: https://github.com/ethereum/go-ethereum/tree/master/accounts/keystore

they support scrypt now

that's just about brain-wallets. the seeds can be derived from real entropy and then password protected, which is generally more secure than deriving the seed from the password

The advantage is they are the dominant player in the cryptocurrency space and we want to achieve integration with their infrastructure and community - especially for things like ethermint and the ether-peg. Having an interoperable key format will facilitate that. It's not necessary, but avoids needing to do format conversions later. That said, everything they do tends to be painful, and Jae usually wants to do something opposite, but the key format looks reasonable.

Here's a liberally licensed js version: https://github.com/ethereumjs/keythereum

[ebuchman]

Let's stick with the armor format we're using now. It's clean and standard, and as of #58 it supports a configurable kdf using the armor headers.