I’ve built an open-source pluggable authentication module called Salt that implements a stateless login mechanism using zk-SNARKs, Poseidon hash, and nonce-bound proof binding, with no reliance on sessions, cookies, or password storage.
Returns a DID-signed JWT (technically a VC-JWT after Zk proof verification). I also have an admin dashboard like Keycloak to manage users. OIDC middlemen — just math.
Key cryptographic components:
- Poseidon hash inside a Circom circuit for efficient field-based hashing of secrets
- Groth16 zk-SNARKs for proving knowledge of a secret (witness) without revealing it
- Every login challenge includes a fresh backend-issued nonce, salt, and timestamp
- Users respond with a ZK proof that binds their witness to this nonce, preventing replay
- Backend verifies the proof using a verifier contract or embedded verifier (SnarkJS / Go verifier)
- No authentication state is stored server-side—verifiability is purely cryptographic
Security Properties:
- Replay-resistant: Every proof must be freshly bound to a nonce (nonce ∥ salt ∥ ts), preventing reuse
- No secrets on server: Users retain the witness; server never sees or stores secrets
- Zero-trust compatible: Designed for pluggable sidecar deployments in microservice or edge environments
- Extensible to VC/JWTs: After verification, the system can optionally issue VC-JWTs (RFC 7519-compatible)
This isn’t another crypto login wrapper—it’s a low-level login primitive designed for protocol-level identity without persistent state.
I’m interested in feedback on the soundness of this protocol structure, hash choice (Poseidon), and whether there’s precedent for similar nonce-bound ZK authentication schemes in production systems.
Could this be a building block for replacing token/session-based systems like Auth0? Or are there fundamental pitfalls in using zk-proofs for general-purpose login flows?
submitted by /u/Parzivall_09
[link] [comments]
