# Management of secrets for token.redeem\_shield **URL:** \ **Category:** Aztec\ **Created:** [March 8, 2024, 1:23pm UTC](https://forum.aztec.network/t/management-of-secrets-for-token-redeem-shield/4923 "2024-03-08T13:23:01Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![oleh](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.aztec.network/oleh/32/919_2.png) [@oleh](https://forum.aztec.network/u/oleh)\ **Post date:** [March 8, 2024, 1:23pm UTC](https://forum.aztec.network/t/management-of-secrets-for-token-redeem-shield/4923/1 "2024-03-08T13:23:01Z")
`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: ```auto 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? ---
**Author:** ![porco](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.aztec.network/porco/32/147_2.png) [@porco](https://forum.aztec.network/u/porco)\ **Post date:** [March 8, 2024, 2:39pm UTC](https://forum.aztec.network/t/management-of-secrets-for-token-redeem-shield/4923/2 "2024-03-08T14:39:52Z")
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. ```auto secret = account.createAuthWitness(serialize(domain_separator, secret_index)) ``` ---
**Author:** ![oleh](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.aztec.network/oleh/32/919_2.png) [@oleh](https://forum.aztec.network/u/oleh)\ **Post date:** [March 8, 2024, 2:47pm UTC](https://forum.aztec.network/t/management-of-secrets-for-token-redeem-shield/4923/3 "2024-03-08T14:47:56Z")
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. ---
**Author:** ![porco](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.aztec.network/porco/32/147_2.png) [@porco](https://forum.aztec.network/u/porco)\ **Post date:** [March 8, 2024, 2:59pm UTC](https://forum.aztec.network/t/management-of-secrets-for-token-redeem-shield/4923/4 "2024-03-08T14:59:24Z")
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? ---
**Author:** ![skaunov](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.aztec.network/skaunov/32/1792_2.png) [@skaunov](https://forum.aztec.network/u/skaunov)\ **Post date:** [October 1, 2024, 1:18pm UTC](https://forum.aztec.network/t/management-of-secrets-for-token-redeem-shield/4923/5 "2024-10-01T13:18:50Z")
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.