Zero-Knowledge Proofs: Proving Without Revealing, Separating Substance From Theatre

A zero-knowledge proof lets one party prove to another that a statement is true whilst revealing nothing beyond the truth of the statement itself: not the evidence, not the underlying data, not the working, only the fact. It sounds like a conjuring trick, and most people, hearing it described, assume it cannot be done. It can.

The technique is not new. It was set out in a 1985 paper by Goldwasser, Micali and Rackoff; two of the three, Goldwasser and Micali, went on to receive the Turing Award, in 2012, for a body of work in cryptography of which this was a part. What has changed recently is practicality. Proofs that once demanded impractical amounts of computation can now be generated quickly enough for production systems, and the phrase has duly made its way from the journals onto the product brochures. That journey has not been kind to precision. What follows sets out what the technique actually offers, where it is earning its keep, and how to spot the cases where the phrase is carrying more weight than the mathematics.

The Idea, Without The Algebra

Consider the proof-of-age problem. A merchant needs one bit of information: is this customer over eighteen? The conventional answer is a passport or a driving licence – a document that hands over name, date of birth, address, document number and a photograph in order to settle a single yes-or-no question. The mechanism is over-disclosure: reveal far more than the question requires, and trust the recipient to use only what it needs and to look after the rest.

A zero-knowledge proof turns that around. The customer’s device produces a cryptographic proof of the statement “the holder of this government-issued credential is over eighteen,” and the merchant verifies that the proof is valid without learning the birth date, the identity, or anything else. The surplus is never handed over, and what is never handed over cannot be retained, breached, or sold on.

Three properties define the construction, and the achievement is that all three hold at once, even against a verifier actively trying to extract more than it is owed. Completeness: a true statement can always be proven. Soundness: a false statement cannot be proven except with negligible probability, so the proof cannot be faked. Zero-knowledge: the verifier finishes the exchange knowing nothing beyond the single fact it set out to check.

This is the same trust problem that runs through much of security. Conventional verification amounts to hand me everything, and I promise to use only what I need – trust extended on the strength of a promise. A zero-knowledge proof takes the promise out of the transaction, and with it the need to trust that the promise will be kept.

Where It Is Real

The clearest near-term trajectory is digital identity and credentials. The EU’s framework does not merely contemplate minimum disclosure; it mandates it. Regulation (EU) 2024/1183 – eIDAS 2.0 – writes selective disclosure and unlinkability into law as core design features of the European Digital Identity Wallet, which every member state must offer by the end of 2026, and the underlying W3C verifiable-credential standards are built to the same shape. Age assurance is the forcing function: regulators across the UK and Europe are demanding age checks at precisely the moment the technology can deliver them without building databases of citizens’ browsing habits. A wallet that answers “over eighteen” without disclosing the birth date is exactly the right shape for that demand. One honest qualification belongs here, because it is the distinction the brochures skate over: basic selective disclosure, which reveals one attribute instead of the whole document, is not the same as true unlinkability, under which two checks of the same credential cannot be tied back to one person. Only the latter leans hard on zero-knowledge techniques; the former can be done more cheaply and often is. It is precisely the distinction a serious procurement should test.

A second, quieter application is proof of computational integrity. The blockchain world, whatever one concludes about the rest of it, has funded a decade of hard engineering on succinct proofs – the SNARK and STARK families – driven by the need to show that a batch of transactions was processed correctly without re-executing every one. Set the speculative froth aside and what that work leaves behind is general-purpose tooling for proving that a computation was performed correctly, with uses well beyond cryptocurrency: proving that the regulated model actually run was the one certified, that a report was derived from the data it claims to rest on, that an outsourced computation was carried out honestly rather than quietly shortcut.

The third, and youngest, is compliance without disclosure. A firm can prove that it meets a solvency threshold, that its sanctions screening was performed, or that some audit property holds, without opening the underlying books to the counterparty asking. These deployments are thinner and patchier than the other two, and it would be misleading to call them routine. But the pattern is the right one for a great deal of business that currently runs on non-disclosure agreements and good faith: the party asking receives the assurance it genuinely needs, and nothing further.

Where Caution Is Warranted

The limits matter as much as the applications, and the brochures tend to leave them out.

The first is that a proof is only as good as the statement it encodes. A zero-knowledge proof establishes exactly the formal claim written into it and nothing adjacent to it. “This credential asserts over-eighteen” is not “this human being is over eighteen” – not if credentials can be borrowed, issued carelessly, or presented from someone else’s device. The cryptography is usually the strongest link in a chain that also takes in issuance, binding to a person, and revocation, and an attacker will go at the weakest link, as attackers always do.

Then there is trusted setup, and implementation maturity in general. Some proof systems require an initial setup ceremony whose compromise would let an adversary forge proofs undetected; others avoid that, at the cost of larger proofs. The implementations are young by the standards of cryptography, and deployed systems have already produced a handful of subtle soundness bugs. None of this rules the technology out; all of it belongs in an assessment rather than in a footnote to one.

Performance deserves the same honesty. Generating a proof is still computationally expensive for complex statements, and a product promising zero-knowledge anything, instantly, on a handset invites one plain question – “for which statements, exactly?” – whose answer tends to separate those who have built something from those who have written a claim.

Most common of all is vocabulary inflation. “Zero-knowledge” has been borrowed by a good many products, storage and password managers among them, to mean nothing more than “we encrypt on your device and cannot read your data.” That is a real and useful property, but it is not a zero-knowledge proof, and a vendor who uses the term loosely in one place should not be assumed to be precise with it anywhere else.

The Sensible Position

Zero-knowledge proofs are not something most organisations need to deploy this quarter, and anyone selling that urgency deserves the same scrutiny as the rest of the urgency trade. What they change is not the roadmap for next month but the range of what it is reasonable to demand. The next time a process asks for a scan of a passport to settle a yes-or-no question, or a counterparty insists on full access to your data to check a single property, the over-disclosure can be seen for what it is: an architectural choice, and an increasingly dated one, rather than a fact of nature. The mathematics for doing better is standardised, implemented, and turning slowly into infrastructure.

It is recommended that minimum disclosure be adopted as a design requirement in new systems and procurements now, rather than retrofitted once regulation compels it. The regulatory direction is already set, and the client expectation is moving the same way; a system designed around handing over the least that answers the question will age well, whilst one built on wholesale collection will not.

Minimum disclosure is becoming a design requirement – written into regulation now, and increasingly into what clients and counterparties consider it reasonable to ask. An organisation that understands these tools before that expectation hardens will find it far cheaper to meet.