> For the complete documentation index, see [llms.txt](https://docs.alephzero.org/aleph-zero/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.alephzero.org/aleph-zero/protocol-details/shielder/deterministic-secret-management.md).

# Deterministic Secret Management

When making transactions the user needs to come up with various secrets: `trapdoor`, `nullifier`  which all must be stored (or at least the most recent one) in order to keep using the shielder. Backing up so many secrets is problematic hence we introduce a deterministic secret management scheme that allows the user to keep just one secret seed and derive all the remaining secrets out of it. 

The simplest attempt at such a scheme could be as follows:

* The user starts by generating a master seed: `seed` with say 256 bits,
* The user generates its ZK-ID: `id = hash(seed, "id")` 
* Whenever a new secret is required, for instance nullifier, it is derived as
  * `nullifier = hash(seed, "nullifier-X")` where `X` is a unique nonce, for instance the index of the transaction or so,
  * `trapdoor = hash(seed, "trapdoor-X")` 
  * similarly for the case of generating randomness for the sake of encryption or `mac` -- special care must be taken to never reuse the same randomness, because it is revealed right away (recall that `mac = (r, hash(r, k))`). If the nonce for generating `r` depended only on the transaction number, then it could happen that the user would use the same `r` when resubmitting a transaction, compromising privacy and maybe even security. 

Note that in the above, the choice of nonces is crucial for security.