bip32: tracking issue for BIP32-Ristretto

[tony-iqlusion]

This is a tracking issue for specifying a BIP32-Ristretto algorithm, providing an initial implementation in the bip32 crate, and creating test vectors that other implementations can use.

Intro

For context, BIP32 is a specification for "hierarchical deterministic wallets", which allows for the derivation of child keys from parent ones. The BIP32 spec supports a "non-hardended derivation" which leverages the commutative properties of elliptic curve points, allowing someone with knowledge of a parent public key to derive corresponding child public keys. Additionally it specifies a "hardened" derivation which relies entirely on secrets known only to the holder of the parent private key.

The original specification was specified for secp256k1 elliptic curve scalars/points, however as Ristretto provides a prime order group, it can be easily adapted to support that as well.

In regard to a concrete implementation in the bip32 crate, the bip32::ExtendedPrivateKey type is already generic over the scalar type used for private keys (which is already leveraged to support both k256::SecretKey and k256::ecdsa::VerificationKey), which would also make it simple to add support for Ristretto as well.

Goals

Stay as close as possible to the original BIP32 construction as specified for secp256k1, retaining the same data structures (e.g. 78-byte binary representation of an extended key).

The motivation for this is to keep the implementation for hardware wallets which already have a BIP32 implementation as simple as possible, and allow them to reuse as much existing code as possible, as well as simplifying the conceptual understanding of the protocol.

Human-readable encoding

The original BIP32 uses Base58Check encoding. This has largely been obsoleted by the Bech32 encoding, and its successor Bech32m, which is used for v1+ SegWit addresses.

As the Base58Check and Bech32 encodings have design flaws, the proposed encoding for BIP32-Ristretto addresses is Bech32m, with no specified Base58Check/Bech32 legacy encoding. This hopefully shouldn't be problematic for hardware wallets, which are likely implementing Bech32m for SegWit support.

Proposed extended key prefixes:

• rprv: Ristretto extended private key
• rpub: Ristretto extended public key

[burdges]

We're using https://github.com/w3f/schnorrkel/blob/master/src/derive.rs in Polkadot, except our path parsing logic exists outside schnorrkel itself, and we slightly miss-used the chain-code there due to internal miss-comunication.

I'd expect Stellar has their own BIP32 analog too. I'm afraid Olge and I failed to synchronize even our signature scheme work. I'd expect almost anyone using Ristretto also uses merlin/strobe for hashing since both come form dalek.

[tony-iqlusion]

Speaking of hashing, key fingerprints are an interesting question.

The standard RIPEMD160(SHA256(pk)) approach is... fine, but it seems like something where a better algorithm could be chosen, and perhaps one more parsimonious with other constructions.