Document architecture of Segregation of Seeds & Keys

[ChristopherA]

FiloSottile/age#277 (comment)

I do not recommend that you should support or recommend converting existing age keys to a BIP39 mnemonic — I believe this to be a bad security practice, as seeds should be solely used to derive keys, not used as keys themselves.

At minimum you should derive a key from the seed by using a pbdkf function with a constant (some good reviewed code for this is in bc-crypto-base, or use a well-vetted BIP32 library (we use lib-wally-core and register a BIP32 derivation path at SLIP-44 with age as a the coin type. BIP32 has the advantage of supporting the ability in the future to have simple revocation or rotation case keys, as you can use key index 0 by default, and rotate to key index 1+ later.

The reason for not using seeds as keys is to avoid collision and reuse with other keys derived from that seed. We've found that most people can only afford the time to properly backup one seed, thus asking people to store lots of seeds is risky. Fortunately there are lots of options to help backup BIP39 mnemonics and derive keys from them safely out there because of the cryptocurrency world.

I don't have a problem for better support of converting a BIP-32 mnemonic based seed to a age key — other than registering the BIP32 coin type, command line is trivial using seedtool-cli and keytool-cli, and there is lots of reliable code out there for doing the same (c, go, rust, javascript, etc.)

@FiloSottile — are you up for submitting a PR to reserve/register a number for age to the SLIP-44 repo? I can then write an example script for you to convert a BIP39 mnemonic to an age key. With that as a proof of concept would be relatively trivial to then have some write a micro-python plugin for age for integration with secure hardware tools like the Trezor, or Airgapped security devices. You don't need to be a cryptocurrency user to leverage their hardware.