Zero-Knowledge Proofs in Node.js: Practical Applications

by Federico Rampazzo

Zero-knowledge proofs sound abstract until you try to build something with them.

How do you prove you know something without revealing it? How do you convince a verifier that a solution exists without leaking the solution itself? And can these ideas be applied to systems we actually build?

This article walks through the intuition behind zero-knowledge proofs, explores a few concrete constructions in Node.js, and examines where they are practical today and where they are not.

What “Zero Knowledge” Actually Means

A zero-knowledge proof is a protocol between two parties:

  • Peggy (the prover), who claims to know a secret.
  • Victor (the verifier), who wants to be convinced.

Peggy wants to prove she knows a value without revealing anything about that value beyond the fact that she knows it.

A valid zero-knowledge proof must satisfy three properties:

  1. Completeness – If Peggy is honest and knows the secret, Victor will be convinced.
  2. Soundness – If Peggy does not know the secret, she cannot consistently convince Victor.
  3. Zero-knowledge – Victor learns nothing beyond the truth of the statement being proven.

That third property is subtle. Formally, it means that the verifier could simulate the entire interaction without access to the secret. If you could “rewind time” and replay the protocol, nothing in the transcript reveals new knowledge.

The easiest way to understand this is through examples.

The Where’s Wally Intuition

Where is Wally?

Imagine a large Where’s Wally puzzle. Peggy has found Wally and wants to prove it without revealing his location.

She places a cardboard sheet over the image with a small cutout exactly the shape of Wally. When she aligns it correctly, Victor sees Wally through the hole, but nothing else in the image.

Victor is convinced she knows the location. He learns nothing about where Wally is.

This is a perfect intuition for zero-knowledge: reveal just enough to prove the claim, but nothing more.

Proving an NP-Complete Solution Without Revealing It

3-coloring problem

Now let’s consider a more typical computer science problem: the 3-coloring problem.

Given a graph, can you assign one of three colors to each vertex such that no two adjacent vertices share the same color?

This is NP-complete. Hard to solve in general. But suppose Peggy has found a valid coloring. She wants to prove it without revealing the coloring.

The protocol looks like this:

  1. Peggy colors the graph correctly.
  2. She commits to the coloring in a way that hides the actual colors.
  3. Victor randomly selects an edge.
  4. Peggy reveals only the colors of the two vertices connected by that edge.
  5. Victor checks they are different.

If the coloring is invalid, eventually Victor will catch a conflict. The more rounds they repeat, the lower the probability of successful cheating.

Victor gains confidence probabilistically. Peggy never reveals the full coloring.

This is an interactive zero knowledge proof.

You can play with a simulation of this problem here.

Removing Interaction: Deterministic Challenges

Interactive proofs are inconvenient in automated systems. We want something non-interactive.

A common trick is to replace the verifier’s randomness with a hash. Both parties agree that challenges are derived deterministically from a random hash value. The prover cannot predict the challenge in advance.

This is the foundation of many non-interactive zero-knowledge systems. Interaction is replaced with deterministic challenge generation derived from a cryptographic hash.

Applying Zero Knowledge to Authentication

The classic username-password flow has an obvious weakness: the password is sent to the server (even if over TLS).

Yes, we hash passwords server-side with salt. Yes, TLS protects transport. But conceptually, we are still transmitting the secret.

Can we authenticate without ever sending the password?

First Attempt: Deterministic Key Generation from Password

The initial idea is straightforward:

  1. Use the password as a deterministic seed.
  2. Generate a public/private key pair from that seed.
  3. Store the public key on the server.
  4. During login:
    • Regenerate the key pair from the password.
    • Sign a message.
    • Send the signature.
    • Server verifies using the stored public key.

Conceptually elegant. No password transmission.

But there is a fatal flaw: cryptographic key generation requires strong randomness. Using a password as the randomness source destroys entropy.

You can try to mitigate repeated patterns. For example, append password length to avoid collisions like:

  • abcabc
  • abcabcabc

But this is patchwork. The root problem remains: passwords do not provide sufficient entropy for secure key generation.

This approach is instructive but not production-safe.

You can find the code here.

A Better Approach: Encrypting the Private Key with the Password

A more realistic model:

  1. Generate a proper key pair using secure randomness.
  2. Store the public key on the server.
  3. Encrypt the private key locally using the password.
  4. Store the encrypted private key in the browser.
  5. During login:
    • Decrypt the private key in the browser using the password.
    • Sign a challenge.
    • Send only the signature to the server.
    • Server verifies using the public key.

The password never leaves the client. The server never sees it.

This closely resembles how SSH keys or hardware-backed credentials work.

You can find the code here.

Trade-offs

  • You must store encrypted material on the client.
  • If the user switches devices, a recovery flow is required.
  • There is additional coordination during registration.

But the advantages are clear:

  • The password is never transmitted.
  • The server cannot leak password-equivalent material.
  • Authentication reduces to possession of a private key.

This aligns with modern PAKE protocols such as SRP and SPAKE2.

Zero-Knowledge Check

  • Completeness: A valid private key can produce a signature.
  • Soundness: Without the private key, forging a signature is computationally infeasible.
  • Zero knowledge: The private key is never revealed. The signature reveals nothing about it.

If RSA or ECDSA breaks, the internet has bigger problems.

Homomorphic Encryption and Zero-Knowledge

Zero-knowledge becomes far more powerful when combined with homomorphic encryption.

Homomorphic encryption allows operations on encrypted data.

For example:

  • Encrypt number A.
  • Encrypt number B.
  • Compute A + B without decrypting either.
  • Decrypt the result.

The Paillier cryptosystem supports additive homomorphism. You can:

  • Add two encrypted values.
  • Multiply an encrypted value by a plaintext value.

This enables more interesting constructions.

Proving Set Membership on Encrypted Data

Suppose you want to prove that an encrypted value belongs to a predefined valid set, without revealing the value.

A technique based on Paillier allows:

  1. Precomputing encrypted values of valid elements.
  2. Using homomorphic operations to construct algebraic checks.
  3. Verifying membership without decrypting the tested value.

The math is non-trivial and relies on specific properties of the cryptosystem. The key point is architectural: we can prove properties about encrypted data without decrypting it.

You can find the code here.

Where Zero-Knowledge Actually Matters

In trust-heavy environments, zero-knowledge is less critical.

If you trust your cloud provider, and your clients trust you, legal frameworks already enforce behavior. Zero-knowledge does not add immediate value.

Cryptocurrency is different. It operates in a trust-minimized environment.

Systems like Zcash and Monero rely heavily on zero-knowledge proofs to:

  • Prove transaction validity.
  • Hide balances.
  • Maintain ledger integrity without revealing transaction details.

The network verifies correctness without knowing the underlying amounts.

That is a fundamentally different design space.

The Real Frontier: LLMs and Encrypted Computation

The more interesting question is what happens as we increasingly outsource computation to external AI systems.

Users provide LLMs with:

  • Personal data
  • Educational performance data
  • Health data
  • Business-sensitive information

Today, that data is processed in plaintext on remote infrastructure.

Homomorphic encryption combined with zero-knowledge proofs suggests a different future:

  1. Submit encrypted data.
  2. Perform computation without decryption.
  3. Receive encrypted results.
  4. Decrypt locally.
  5. Verify correctness via zero-knowledge proof.

The provider never sees the raw data.

The obstacle is performance. Fully homomorphic encryption is still orders of magnitude slower than plaintext computation. Running large models this way is currently impractical.

But the direction is clear. As performance improves, provable computation on encrypted data becomes viable.

When that happens, zero-knowledge will move from academic curiosity to architectural necessity.

Engineering Takeaways

Zero-knowledge proofs are not magic. They are protocols with explicit trade-offs:

  • Interactivity versus determinism.
  • Performance versus privacy.
  • Storage complexity versus secret transmission.
  • Cryptographic assumptions versus operational trust.

In authentication, we already use zero-knowledge style constructions in PAKE systems and public-key challenge-response flows.

In distributed systems, homomorphic encryption plus zero-knowledge enables verifiable outsourced computation.

Design systems that prove properties instead of revealing data.

That shift in mindset leads to different primitives, different threat models, and different system boundaries.

Zero-knowledge is not about hiding everything. It is about revealing exactly what is required, and nothing more.

Written by

Federico Rampazzo
Federico Rampazzo Senior Software Engineer