Confidential Login

For confidential logins, the system uses JWT (JSON Web Tokens) as the private witnesses in a zero-knowledge circuit that verifies the provider’s digital signature and user information. Particle’s system also uses the Particle Chain, a proprietary zkEVM powered by the network’s native universal gas token, to generate ZK-proofs. Although with key differences, the overall design derives inspiration from Sui’s zkLogin.

Now, let’s dive deeper into how the Confidential zkStack achieves its goal of providing identity privacy.

Achieving identity privacy

To onboard users while protecting their privacy, our zkStack uses a system where users first generate an ephemeral keypair while simultaneously going through a verification process. Then, they use their verified credentials to generate a ZK-proof through the Particle Chain, which they submit to a verifier to conclude the process.

This is diagrammed below:

Elaborating further, confidential logins work as follows:

A) Set Up

To create the common reference string (CRS) for the Confidential Login circuit, Particle uses Groth16 –but may consider zkSTARK in the future. The trusted setup generates a proving key and a verifying key for the OAuth provider. Particle is currently also working towards a non-trusted setup.

B) Signing

1. Ephemeral key generation: When a user accesses their wallet, an ephemeral KeyPair is generated. The user then chooses a max epoch, which defines the keypair’s expiration date.
2. The app prompts the user to authenticate through an OAuth provider sign-in using a custom nonce constructed using randomness, the ephemeral key, and the max epoch (decided by the user, which determines how long before the ephemeral keys expire and they need to be generated again).
3. This process returns a JWT containing a header and payload.
4. The JWT is sent to a salt service, which returns a unique salt –a random numeric string– upon validating the JWT.
5. The JWT, salt, and ephemeral public key are sent to the Particle Chain, which uses them to generate a ZK-proof of the complete claim and sends it to the on-chain verifier.
   The claim states that:

i) The nonce is correctly formed, and includes the public key.

ii) The key claim is consistent with the JWT.

iii) The Particle address is consistent with the key claim and salt.

iv) The OAuth provider's signature is correct.

Along with the zk-proof, the address seed, claims, and header are sent to the dApp.

Note that the circuit generates a zk-address for the user. The user creates a transaction and signs it to get an ephemeral signature. They also send other information, including the ephemeral public key, signature, proof, address seed, claims, and header.

C) Verification

Two types of verifications are possible:

1. Smart contract verification on the Particle Chain.

2. Decentralized verification by the Particle Chain’s validators, who are rewarded by the system in Particle Network’s tokens.

Verification process:

The verifying entity receives the users’ information. They then conduct the following checks:

1. Verify the transaction's sender: Ensure that the transaction's sender is derived from the address seed and matches the revealed claims.

2. Verify the signing user against the user’s public key.

3. Verify the ZK-proof.

4. Retrieve the public key and check whether it is the same one used in the ZK proof.

D) Storage

Once the user is authenticated, a map is stored on-chain for automatic logins until the user’s selected epoch expires.