Privacy Legos pt. II: What are Nullifiers?

Privacy Legos pt. II: What are Nullifiers?

Nullifiers are like your private keys in Holonym ???except they’re more private because they don’t have a corresponding public key that everyone can see.

Previously, we talked about the privacy pool (anonymity set) but the simplified description had a couple of problems. One is it would be pretty insecure: someone can brute-force or dictionary attack the leaves in tree and guess the identities behind them!

Privacy Legos pt. I: The anonymity set, a.k.a. “privacy pool”

This is why there should be some randomness to the identities before hashing them. The random string added is called a “pepper” ?? and in Holonym it is used as a nullifier ?? Not only does the pepper prevent dictionary attacks, it also lets you nullify yourself.?

???What is nullifying yourself? It’s when you restrict yourself to perform unique actions once and only once. Imagine paying someone — you don’t want the recipient to be allowed to spend it twice! You do this by making them publishing a (provably correct) hash of the nullifier so they can’t use their nullifier again.

Lets look at an example in Holonym where the nullification is needed:

You want to airdrop your users but you don’t want bots to farm and dump your tokens. So you need to prove all your users are unique people. You create a Merkle tree to store commitments to government IDs for each of your users. This way a valid airdrop recipient can prove knowledge of a government ID and corresponding pepper that make up one of the leaves in the tree.

But if they’ve just proven they know an ID+pepper, they have only shown they’re a real person, not that they’re a unique person! In fact, they can even prove this many times to claim the airdrop many times. Enter the nullifier ??

The proof must also require the airdrop recipient to show a nullifier hash. This doesn’t reveal the nullifier which only the user knows. Rather, it reveals the hash of this value. Now, if the user tries to prove they’re a real person twice, they’ll use the same nullifier hash — clearly it’s the same person if the nullifier hash has been used twice!

In practice, Holonym doesn’t just use the nullifier hash, it often uses a salted nullifier hash, i.e. salted pepper hash, ?????. This is because a user has one nullifier yet they want to have freedom to act anonymously from multiple addresses — publishing the same nullifier hash for all actions would link those addresses together.?

For context, salts are random public values added to a pre-image before hashing. They’re used in password databases so instead of storing hash(password) hashes, you store hash(password+salt). That way, someone who steals the db can’t say “ah, their password hash is 124123…. — that’s the hash of a common password, ILoveDucks,” Because you’re using a unique, random salt, preventing dictionary attacks between common passwords and their unique digests.

Recap: The nullifier hash nullifies the Merkle leaf from being used twice for the same proof. The nullifier also acts as a pepper to prevent brute-forcing. Salts are used to prevent the user from having two actions with the same nullifier hash. ??+??=#??

Interested in helping us create a future where privacy in the digital world is ensured? Join our Discord: https://bit.ly/3tOyr0V

要查看或添加评论,请登录

human.tech by Holonym Foundation的更多文章

社区洞察

其他会员也浏览了