Deriving keys from web accounts

Decentralization and Speed Through zkInjectedMask

It has become popular to authenticate to wallets with JWTs. Decentralization has been nearly impossible since this JWT serves as 'keys to the kingdom' and every node who receives it can steal the user's key.

What's more: approaches are also often based on distributed key generation for each user, which has difficulty scaling to highly decentralized network with millions of users.

Luckily both of these can be solved with zkInjectedMask. In zkInjectedMask, possession of their JWT is not enough to derive a user's key. It involves no DKG, and requires no communication between nodes.

How this works

zkInjectedMask works in the following way:

let userHash be a hash function that takes a JWT and hashes the important claims (e.g. sub, iss, aud) that uniquely identify the user at the particular website they log in from. Its output is a uniformly random point on an elliptic curve.

1. User generates a private and public masking key

$$(m, M) | M= mG$$

2. User requests to the JWT provider to include M into the JWT. This only works when JWT issuers allow the frontend to set a custom claim such as nonce

3. User sends (JWT, m*userHash(JWT)), and a DLEQ proof that m really was multiplied by it.

4. Network verifies the proof that JWT's public masking key corresponds to the private key used to mask it. If so, the network responds with a threshold scalar multiplication of its secret key s by m*userHash(JWT)

5. User unmasks the network's response s*m*userHash(JWT) by multiplying it by m's inverse:

$$m^{-1}*s*m*userHash(JWT) = s*userHash(JWT)$$

Finally, the resulting value is hashed to get a pseudorandom function of the JWT's salient claims. This is the same PRF used in the 2HashDH OPRF.

This scheme prevents replay attacks since while anyone can replay the user's request (JWT, m*userHash(JWT)), they can't get a meaningful response from the network. To do so, they would need to unmask it by knowing the inverse of m .

Note: The use of ZK does not hide the JWT from the network. It simply prevents the JWT from being replayable by malicious nodes. It is recommended to use JWTs that do not reveal personally identifying information.

Note: No matter how decentralized Mishti network is, JWTs are typically issued by centralized companies. For decentralized use cases, we recommend using JWTs be used as one of multiple authentication or authorization methods. However, we do not suggest using it as the only one.

zkInjectedMask Sequence Diagram