Management of secrets for token.redeem_shield

token.redeem_shield(to, amount, secret) requires user to know the secret to redeem shielded tokens. If secrets are generated randomly, there should be a database (local on user machine or global on Aztec servers) to store user secrets. I can clearly see the cons of this approach:

  1. In case of a local DB, secrets can be lost if user loses/changes their phone
  2. In case of a global DB, user puts trust in Aztec (or other 3rd party) servers and if those go offline for any reason, user secrets are lost.

I am thinking about deterministically deriving secrets from user’s private key. An example formula:

secret = hash(private_key, domain_separator, secret_index)

With this approach a user can derive their secrets with a simple for loop on any device without relying on any third parties.

Questions:

  1. Is this secure and privacy preserving?
  2. Any other methods of managing user secrets?
33 Likes

Apps asking users to provide their private keys practically sound a bit insecure. How about using a witness? Not entirely sure if that’s also secure enough due to its deterministic nature, but at least it’s handled on the wallet side, as if Metamask asks users to sign a message.

secret = account.createAuthWitness(serialize(domain_separator, secret_index))
27 Likes

The secret generation is done inside wallet software, so it has access to the private key anyway. I am thinking about an RPC call like “aztec_secretHash” that will return a secret hash to an app. Then the app can use the secret hash. After that, token.redeem_shield is called inside WALLET software to not leak the secret to the app.

19 Likes

Ahh, you are right. In the context of my idea, createAuthWitness should be wrapped by another function that also hashes the secret.

So there needs to be a rpc func exposed for redeeming too?

21 Likes