Introduction
In blockchain and PKI more generally, people are represented by keys. A somewhat strange question to ask might be “why don’t keys represent people?” I will argue this is actually an important question and the crux of major privacy and onboarding challenges. We present a a threshold network design dubbed Mishti Network to derive keys from people rather than arbitrary randomness. This network solves a number of problems in ZK identity, compliance, and onboarding.
What does it mean for a key to be a representation of a person? There are two conditions that should be met:
- A person’s knowledge and/or attributes can always map to the private key
- This person is the sole controller of the key
In other words, it is a collision-resistant map of personal data and attributes to a high-entropy pseudorandom number. Without collision resistance, multiple people could have the same key. Without high entropy, the key is not secure. Keys can be both standard private keys or also a nullifier that’s useful for secure ZK credentials.
Human keys are not solely biometrics. They could be from human-friendly data such as security questions, passwords, or any unique knowledge belonging to an individual rather than arbitrary randomness.
Solution: Oblivious Pseudorandom Function
This solution is based on a threshold verifiable oblivious pseudorandom function (tVOPRF) on private data. An oblivious pseudorandom function (OPRF) takes a private input and computes a pseudorandom function (PRF). PRFs take low-entropy input and create high-entropy output. Adding verifiability via a ZKP makes it into a VOPRF. Verifying individual node contributions is important to decentralizing the network.
Why it is helpful to Ethereum + PKI
Some of the outstanding issues in Ethereum are onboarding and privacy. Onboarding requires not just simplicity but also self-custody, and recovery. Current onboarding solutions such as social logins and passkeys do not have self-custody (as they can be recovered by web2 accounts), while self-custodial solutions can’t have recovery without extra onboarding step like electing gaurdians.
A similar need is for ZK identity applications that need to derive nullifiers from their users’ identities, in a way nobody can trace back to the user. This is a common need in proof-of-personhood solutions to ensure that each person only has one corresponding nullifier without a central database or key that links users to their nullifiers.
Furthermore, the underlying cryptography and network can be repurposed to tackle another pressing challenge: that of satisfying compliance rules with ZK identity. The same underlying elliptic curve multiplication primitive that underlies this design can be used to construct threshold ElGamal decryption over ZK-friendly curves, which can allow ZK proofs to contain encrypted data with flexible access control.
Oblivious Pseudorandom Function
To generate keys from identities, an oblivious pseudorandom function (OPRF) can be constructed with distributed EC scalar multiplication. This allows private user data such as security questions, biometrics, passwords, or social security numbers, etc. to deterministically generate secret keys. The resulting pseudorandom value is computationally impractical to reverse despite it being from low-entropy input. One can thereby create wallet or nullifier from any (or a combination) of these low-entropy “human” factors. In the 2HashDH OPRF [1], a server or network’s secret is used to give randomness to the client’s input. The oblivious property prevents any server or set of nodes from seeing see this input.
2HashDH is the following algorithm between a user with a private input x and a server (or network) with a private key s. For a subgroup G of an elliptic curve there are two hash functions:
hashToCurve: \{0,1\}^* \rightarrow G
hashToScalar: G \rightarrow F_q.
The 2HashDH OPRF proceeds as follows
- User samples a random mask r and sends M = r * hashToCurve(x)
- Server multiplies by its secret, returning s * M
- User computes the output by unmasking the server’s response and hashing it: o = HashToScalar(r^{-1} * s * M)
o is uniformly pseudorandom in F_q, and the server is information-theoretically blinded from the user’s input.
Decentralizing the server
To decentralize the OPRF server, only the step with a server must be decentralized:
- Server multiplies by its secret, returning s * M
For threshold elliptic curve multiplication, first a linear secret sharing, such as Shamir’s scheme, must be used. The secret key is generated through distributed key generation (DKG) such that each node with index i receives share f(i) for some secret polynomial f known to nobody. There is no node at the 0 index and f(0) is the secret key of the network. The secret key f(0) can be computed by a set Q of t nodes where t is one more than the degree of f.
f(0) = \sum_{i \in Q}{L_{0, Q}(i)*f(i)}
where L_{0,Q}(i) is the Lagrange basis for index i in set Q evaluated at zero.
Instead of reconstructing f(0), the nodes can collaborate to construct f(0) * M
f(0) * M = \sum_{i \in Q}{L_{0, Q}(i)*f(i) * M}
This is sufficient for step
- Server multiplies by its secret, returning s * M
if the nodes are honest. But if one lies, the result will be wrong and there will be no way of knowing who lied. Thus, each node should prove their individual multiplication using a lightweight zero-knowledge DLEQ proof.
Other interesting use case: Provable encryption with programmable privacy
The same decentralized EC scalar primitive can be used not just for VOPRF but also for ElGamal decryption over ZK-friendly curves. This is helpful when identities must be revealed in certain conditions.
For example, many private DeFi protocols are interested in ensuring that bad actors do not get the benefits of anonymity, while the average user typically does. Governments are not satisfied with solely ZK because they need access to user data, but currently the only alternative is honeypots where all user data is stored to be turned over to authorities if needed.
Another use of revealing provably encrypted identities under certain conditions is undercollateralized lending – what if you want an identity or private key to be revealed if a DeFi loan is defaulted on? In this case, you need to prove the proper data is encrypted correctly, then have a smart contract control decryption rights.
To modify this threshold EC point multiplication to such use cases, little is needed.
Encryption
ElGamal encryption is client-side:
- Create an ephemeral keypair (a, A = aG)
- Encode the message as an EC point P
- Compute Diffie-Hellman shared secret with network public key: aB
- Compute the ciphertext (A, aB+P)
Decryption
Unlike encryption, decryption requires a server or decentralized network.
- Server/network multiply ephemeral public key A by its secret key b to get bA = aB
- Decryptor subtracts this value from aB+P to get P
The server/network’s step can be handled by the same threshold multiplication protocol as before!
Network Setup and Collusion Protection
The team at Holonym has implemented this as as an AVS on Eigenlayer called Mishti Network. High reputation is common among Eigenlayer operators despite the permissionless nature, so it is ideal for threshold networks where collusion is a concern. To further mitigate collusion risk, there is the idea of parallel networks:
The asynchronous and homomorphic nature of the computations means users can permissionlessly add nodes outside of Mishti Network that they trust to not collude with Mishti Network. E.g. instead of splitting a secret between Mishti Network, half of the secret is between the Mishti Network and the other half in a semi-trusted node elected by the user. Since the whole network just does an EC multiplication, exactly what its individual does do, nodes and networks can be treated the same. A 2/2 scheme could be done between a semi-trusted node and Mishti network, simply by
- Adding their public keys to get the joint public key
- Adding their responses to get a joint response to the computation
Note this requires no consent from the network and is not limited to 2/2 schemes; it can be done with any combination of semi-trusted nodes and/or independent networks via threshold schemes.
References
[1] S. Jarecki, A. Kiayias, and H. Krawczyk, “Round-optimal
password-protected secret sharing and T-PAKE in the password only model,” in International Conference on the Theory and Application of Cryptology and Information Security. Springer, 2014 pp. 233–253
Concluding Notes
If you have any ideas on how to improve or elaborate on this network design for either ZK identity, self-custody, or any other relevant use cases, please reply or reach out.
