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.