Finalizing wallet format

Research
1

Moving notes and conversations from Slack and other channels here for posterity. I’m working on finalizing our cryptography, key generation (including HD derivation), and wallet file format. You can track the project in this issue.

I’m working on finalizing the following things:

  • Curve (ed25519)
  • DSA
  • HD algorithm (e.g., BIP32, EIP-2334)
  • coin_type for HD path: 540
  • wallet file format (JSON, encrypted using some form of authenticated encryption, see EIP-2335) including serialization format and text format (e.g., UTF-8 NFKD)
  • details of AE (cipher, MAC, salt, etc.) used in wallet file
  • KDF
  • pseudo-random function
  • params, including iteration count and seed length
  • which standards, if any, we adhere to (e.g., BIP32, BIP39, BIP43, BIP44, EIP-2333, EIP-2334, EIP-2335)

We considered the Schnorr-based “sr25519” standard used by Polkadot/Substrate (see links below), which is claimed to have the following benefits:

  • It is better for hierarchical deterministic key derivations.
  • It allows for native multi-signature through signature aggregation.
  • It is generally more resistant to misuse. (“schnorrkel/sr25519 uses the Ristretto implementation of section 7 of Mike Hamburg’s Decaf paper, which provide the 2-torsion free points of the Ed25519 curve as a prime order group. Avoiding the cofactor like this means Ristretto makes implementing more complex protocols significantly safer”)

However we decided against it because these benefits aren’t relevant to us at this stage and ed25519 is a more battle-tested standard. We need to make sure we do HD derivation in a way that’s both secure and compatible with hardware wallet support.

CC @iddo, @talm

References (see others in above-linked issue):