recovery seed #52

New issue

Open

opened 2025-03-16 13:08:47 +13:00 by mikedilger · 0 comments

mikedilger commented

2025-03-16 13:08:47 +13:00

(Migrated from github.com)

Master keys are great, but they do have to be used from time to time, and thus could in rare cases be compromised, or more likely they will be accidentally lost.

We could start from a recovery seed which would be 32 bytes encoded into seed words (or similar), PLUS a passphrase.

Then the masterkey could be a f(recovery_seed, passphrase) where the f() is algorithm dependent (in case of multiple algorithms). Some cryptosystems don't allow every 32-bit number as a private key, so in those you would have a more complex key generation algorithm deterministically seeded by the recovery seed and passphrase.

The nice part here is that the recover seed is human-readable and human-typeable, as is the passphrase which ordinarily is also human-memorizable. So you can write these down and store them in a safe somewhere to never loose your master key.

These could also be used, in case of emergency, to burn an account or override an operation performed by a stolen master key, but to do that we need a more-master-than-master master key that isn't human readable / human typeable. So the chain would be SEED+PASSPHRASE --> ACCOUNT RECOVERY KEY --> IDENTITY KEY --> DEVICE KEYS. Since the account recovery key is only used in extreme circumstances, it can be kept in cold storage too. Of course the functions must be such that it is provable that the higher key owns the lower key.

Master keys are great, but they do have to be used from time to time, and thus could in rare cases be compromised, or more likely they will be accidentally lost. We could start from a `recovery seed` which would be 32 bytes encoded into seed words (or similar), PLUS a passphrase. Then the masterkey could be a `f(recovery_seed, passphrase)` where the `f()` is algorithm dependent (in case of multiple algorithms). Some cryptosystems don't allow every 32-bit number as a private key, so in those you would have a more complex key generation algorithm deterministically seeded by the recovery seed and passphrase. The nice part here is that the recover seed is human-readable and human-typeable, as is the passphrase which ordinarily is also human-memorizable. So you can write these down and store them in a safe somewhere to never loose your master key. These could also be used, in case of emergency, to burn an account or override an operation performed by a stolen master key, but to do that we need a more-master-than-master master key that isn't human readable / human typeable. So the chain would be SEED+PASSPHRASE --> ACCOUNT RECOVERY KEY --> IDENTITY KEY --> DEVICE KEYS. Since the account recovery key is only used in extreme circumstances, it can be kept in cold storage too. Of course the functions must be such that it is provable that the higher key owns the lower key.