Thoughts identity switching via --profile.

[enzoh]

BIP32 and BIP39 really lay the groundwork for what I would like to see. The basic idea is that the user would store a single mnemonic seed in their home directory, and not a private key which is currently the case. From the the mnemonic seed, a master private key would be derived . That master private key could then be used to derive child private keys which would actually do the signing. --profile would alias the child private key as so:

func DeriveChildKey(masterKey *bip32.Key, profile string) *bip32.Key {
	var (
		childKey *bip32.Key
		err      error
		index    uint32
	)
	digest := fnv.New32()
	_, _ = digest.Write([]byte(profile))
	index = digest.Sum32()
	for {
		childKey, err = masterKey.NewChildKey(index)
		if err != bip32.ErrInvalidPrivateKey {
			break
		}
		index += 1
	}
	return childKey
}

[eftychis]

Context: See #616, 617, 618 and https://github.com/dfinity-lab/sdk/blob/master/docs/design/user_profiles.adoc.

I think this fits pretty easily to existing work (merged and unmerged). My main question here is why store the mnemonic? The only disadvantage of this approach is that you can not "revoke" the master key, and you rely on the forward secrecy of the master - private key -- I need to review the above proposals for that. Otherwise this should be easy to add after 616 and 617 make it in.

[eftychis]

@enzoh can you find some rust or C libraries to go over and assess, so we can decide on options?

(I see a rust bip39-rs linked in the proposals but I am not familiar personally.)

cc @Dfinity-Bjoern Please take a look ^^

[eftychis]

Also another question: we want multiple profiles per mnemonic? I would assume we would want to allow a separate mnemonic per profile.

[enzoh]

This topic is currently being tracked here #883

[Dfinity-Bjoern]

I don't see a reason for storing the key as mnemonic. I view mnemonics as a tool for user interaction, not something that one would use within a tool. That said, there's no cryptographic weakness of storing mnemonics. But I guess mid-to-long term it would make sense to store keys (as keys) in the OS key rings or some other more secure place.

Whether we want to use derived keys is, in my opinion and for now, mostly a UX question. We would, for now, not use the counterpart in the replica, but that does not mean we should not use derivation on the client side.

[enzoh]

Closing this issue since we are currently tracking it via #883