Management of secrets for token.redeem_shield

Aztec
1

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?
36 Likes
2

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))
48 Likes
3

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.

41 Likes
4

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?

32 Likes
5

I was thinking about the whole design approach to this… How significant is the difference between current transparent note redeem to an unknown address and if it was straightforward shield to the same address (without transparent note) and then just transfer to that unknown address? Or am I just can’t see some other capabilities transparent note enables?

It’s a great pattern for tutorial. But I feel I’m missing something. =( Both ways the public-to-private note can be linked to the address thanks for the public part of the tx. But then nobody knows when that note is spent/popped from the address private set… Or is it because we want to confine PrivateSet belonging to an address from leaking any metadata via public enqueued part? I’m trying to identify what is tremendously improved on that direction with having transparent notes.

(I got the following list from the Docs AI)

… However, some indirect observations can be made:

  1. Nullifiers: When notes are added or removed from a PrivateSet, nullifiers are emitted to signify that certain notes are no longer valid. These nullifiers are observable, … .
  2. Encrypted Logs: … logs can be observed, but their contents remain private unless decrypted by the intended recipient.
  3. Storage Slot: The storage slot of the PrivateSet is a logical construct and does not directly reveal information about the state changes. However, the fact that a storage slot is being used and manipulated can be inferred.
  4. Length Changes: The length of a PrivateSet is not directly observable. The PrivateSet type abstracts away the details of how many notes it contains, focusing instead on the aggregate value or state represented by the set.
1 Like