Key hierarchy proposal

[maurice]

@cwgoes

@maurice Is that accurate?

That’s accurate.

I’ll just point out that the product requirements specify that users can use MetaMask and do not need to download a different browser extension or back up a different seed phrase. The availability of the decrypt functionality was not directly a requirement but rather required as a consequence of the ‘concepts’ section of the PRD and our believe that we would need to encrypt and store the generated keypairs (instead of regenerating).

[vveiln]

@maurice

I cannot follow your points here.

My point was that, from my understanding, one of your arguments was based on the fact that users might not use Metamask, and the other was based on the fact that they will. Perhaps I misunderstood you there.

@cwgoes

I don’t think we should try to make a final long or even mid-term decision about key hierarchies yet, for reasons beyond these specific questions – e.g. we’ll probably want a different, more sophisticated shielded sync mechanism in the future.

But it seems that we are making them. What we are trying to achieve with this approach is to avoid the need to store anything anywhere in the case the user needs to recover their Anoma wallet from a completely different device only having access to the Ethereum wallet (so, not so new?), as far as I understand. So we are making a promise of it being possible, and the moment we want to bring back the independent keys (which might require updating the existing keys users use), we will bring back the need to store something somewhere in case the user wants to sign in from a completely new environment. As I understand, what is considered to be a worse UX.

@cwgoes

The AnomaPay demo may use only a subset of the key hierarchy we support for Galileo overall, but it shouldn’t require something completely different.

I would argue that this is not a subset, it is completely different. The danger is that it looks pretty similar but has completely different properties.

@cwgoes

For example, we could probably obtain a form of key rotation by signing over different messages (and thus deriving different keys)

Technically true, but if the messages we sign are deterministic, it only helps in case only the signature itself is leaked, not the identity key. Leaking the signature, btw, probably is easier since signatures are not considered private, so any external functionality will not be cautious if the user will be asked to reveal their signature - totally valid action. Signatures are meant to be public.

@cwgoes

Maybe we want to derive just an identity key from the signature, generate other keys independently, and encrypt them to that derived identity (public) key.

To correct the terminology: the identity key is the key encapsulated in the wallet, but the idea of generating a key that is used to encrypt the backed up independently generated keys sounds like a better idea to me. It does allow independent rotation, but the security is still bound to the security of the signature (used to derive encryption keys used to store the secret keys on-chain)

We do have inconsistent promises, it seems to me. We say the app is only meant to be a showcase (so we can have worse security for now) yet we showcase the “long-term” functionality (recovery of the Anoma “wallet” only having access to the Ethereum wallet) that is improved by having worse security.

If we want to introduce dependency for the keys as a product requirement, it isn’t up to me to change that (seems like I am trying anyway ). But in that case, I would explicitly separate the long-term key hierarchy (application-independent; the proposal from this post, or the version of it that corresponds to our long-term security desires) from the way we generate keys in AnomaPay and have an explicit plan of moving from the current AnomaPay way to the intended way that takes into consideration all long-term use cases.

[kike]

@pedro

Ex: If we deterministically generate all the keys based on a signed message, and the user is scammed by a phishing attack asking to sign the original message, all keys are compromised.

Just bringing this to attention. It is the most obvious and first-to-try attack.

The mitigation would be to store privately the message in the wallet, i.e the message is also a source of entropy. (But since this seems to require source code modification, then it would be just better to use a standard key-derivation instead of signatures )

[maurice]

Just to make sure - the unlikely event of compromising the signature (i.e. compromising the 3 static keypairs) DOES NOT lead to loss of funds. It would lead to loss of privacy as the attacker could index transactions and decrypt the resourcePayload of indexed transactions. However, at least for the current shielded transfer application, only compromising the identity key itself can authorize spending of resources. Again, the identity key == MetaMask key is well protected as this security is the bread and butter of wallets.