Skip to content

PATTERN Cited by 2 sources

ZKP capability disclosure

Pattern

Prove possession of a dangerous capability using a zero-knowledge proof instead of publishing the capability itself. Defenders update their threat models on the verified existence of the capability; adversaries gain no technical information about the capability they can apply.

Formally:

  • Statement: "I possess algorithm / construction / observation X with parameters P."
  • Proof artefact: a ZKP bound to the statement that convinces any verifier the statement is true.
  • Verifier set: the full public — not a privileged subset under NDA. Anyone with public parameters can audit the proof.
  • What remains secret: the object itself (the algorithm, the circuit, the exploit primitive, the dataset).

The pattern collapses the classical disclosure dilemma from "publish-or-not?" to "publish the proof and withhold the object" — a strictly better Pareto point on the two axes of defender empowerment and adversary enablement.

When to apply

All three conditions should hold:

  1. The object is too dangerous to publish but too important to keep completely secret. Examples: a new quantum attack on a currently-deployed cryptosystem; a zero-day in a trust anchor used by billions; an observation of an active adversary capability. Full disclosure hands the object to adversaries; no disclosure denies the defender community the signal it needs to act.
  2. The community's response depends on trust in the claim. Migration timelines, infrastructure investment, regulatory action, or asset re-pricing requires more than "trust us." Either the claim is independently verifiable (via peer review, reproduction, or ZKP) or it is effectively a private notification.
  3. A FUD attack surface exists. On systems where public confidence is a load-bearing part of value — cryptocurrencies, federated trust, public-safety communication — the disclosure's trust-surface effect must be defended in addition to its technical-surface effect. A private notification under NDA cannot move the public-trust surface at all; a ZKP can.

Canonical instance the wiki indexes: Google's 2026-03-31 disclosure that it has improved the quantum algorithm for breaking ECDLP-256. All three conditions hold:

Components

Five pieces of the disclosure package, as instantiated by the 2026 Google disclosure:

1. The proved statement

Precisely-scoped claim: what algorithm / capability, on what input parameters, with what resource bound. The choice of statement is load-bearing — observers can only verify what is proved. A vague statement "we broke ECDLP-256" has lower operational value than a concrete "we possess an algorithm reducing the qubit cost of breaking P-256 by factor F on architecture A."

2. The proof artefact

A zero-knowledge proof on the statement. In 2026 this is typically a SNARK / STARK / Bulletproof / Halo / Plonk construction; Google's 2026-03-31 post describes it generically as "a state-of-the-art cryptographic construction called a zero-knowledge proof" without naming the specific system. (Source: sources/2026-03-31-google-safeguarding-cryptocurrency-by-disclosing-quantum-vulnerabilities-responsibly)

3. Scope clarification

Bounding what is and is not affected, as part of the disclosure. Protects against the FUD worst-case- narrative problem by making the worst case explicit. Google's 2026 disclosure: "clarify the areas where blockchains are immune to quantum attacks."

4. Defensive-progress highlighting

Citing existing mitigations in the ecosystem — PQC deployments already shipped, standards already finalised, vendor roadmaps already public. Blunts the FUD-potential of "this breaks everything and nothing is being done." Google's 2026 disclosure: "highlight the progress that has already been achieved towards post-quantum blockchain security."

5. Open-norms invitation

The pattern is new enough in 2026 that a finalised governance framework does not exist. The disclosure explicitly invites the quantum / security / cryptocurrency / policy communities to converge on disclosure norms. This positions the ZKP-capability- disclosure artefact as one contribution to an unresolved policy conversation rather than a claim of having solved it.

Contrast with alternatives

Alternative Defender signal Adversary signal Trust-surface effect FUD protection
Full disclosure (peer-reviewed paper) High High — hands the algorithm to all adversaries Public confidence hit, migration tractable Low — the technical claim is public but so is the capability
No disclosure Low Low Public confidence intact, migration stalled N/A
Private NDA notification High (for the insider set) Low (within the NDA set) No market-visible signal N/A — market cannot update
Coordinated disclosure + CVE (classical security) Medium (vendors get a window, public gets detail on public date) Medium — detail published Normal CVE cycle Medium — CVE is auditable
ZKP capability disclosure High (verifiable signal) Low (object withheld) High — proof artefact is auditable substrate for trust High — claim is mathematically verifiable, FUD-asymmetry closed

The ZKP row strictly dominates no disclosure and private NDA notification on defender signal. It dominates full disclosure on adversary signal. It dominates unsubstantiated public claim on trust-surface effect.

The pattern is not free — see caveats below — but it moves the Pareto frontier of disclosure design.

Consumer-side experience

From Cloudflare's 2026-04-07 consumption of Google's disclosure:

They did not reveal the algorithm, but instead provided a zero-knowledge proof that they have one.

Cloudflare's operational response: pull forward the full-PQ- security migration target to 2029, across the entire product suite. This is the pattern's intended effect — credible signal triggers real-infrastructure-spend behaviour change.

The consumer's epistemic position:

"Google has proven it has a capability meeting specified criteria; we cannot independently verify the algorithm; we must plan as if the capability exists at the claimed performance envelope."

This is a qualitative change from the prior model — "trust peer-reviewed hardware benchmarks and algorithmic papers" — to a new "trust a proof of a secret." See concepts/zero-knowledge-proof for deeper analysis of the trust implications.

Caveats

  • Observers can only verify what is proved. The choice of statement is the disclosing party's choice. If the statement is loose ("we have a speed-up of factor ≥ 2") or strategically framed ("on a specific architecture most adversaries haven't prioritised"), the proof is still sound but the operational implication is different.
  • Calibration of the proved statement requires trust. Whether the proved statement maps to a production-threatening capability vs a benchmark-gaming curiosity depends on parameters the disclosing party chose.
  • ZKP construction itself must be trustworthy. The proof system (SNARK / STARK / etc.) must be audited; the trusted setup (if any) must be verifiable; the public parameters must be distributed transparently. A subtly-broken ZKP construction can produce false convictions.
  • Does not solve all disclosure problems. ZKP-capability- disclosure fits capabilities with a precise mathematical statement. It does not fit:
  • Vulnerabilities requiring patch-and-deploy (CVEs) — here the object is the fix-needed thing; withholding it doesn't help.
  • Social / operational compromises — "we have ongoing access to X" is not naturally a ZKP-able statement.
  • Policy claims — "this is ethical / legal / responsible" doesn't have a mathematical proof.
  • Open governance. As of 2026 there is no community-standard format, verifier registry, or embargo discipline for ZKP- capability disclosures. Google's 2026-03-31 post explicitly declines to claim a finalised norm.
  • Performance cost. Producing a ZKP for a non-trivial statement can be computationally expensive (hours to days). Verification is cheap but the proving side's overhead constrains how often / how granularly the pattern can be used.

Seen in

  • sources/2026-03-31-google-safeguarding-cryptocurrency-by-disclosing-quantum-vulnerabilities-responsibly — producer-side canonical instance. Google Research's 2026-03-31 disclosure post. States the pattern explicitly: "substantiate our resource estimates without sharing the underlying quantum circuits by publishing a state-of-the-art cryptographic construction called a zero-knowledge proof, which allows third parties to verify our claims without us leaking sensitive attack details." Includes the full five-component package (statement + proof + scope clarification + defensive-progress + open-norms invitation). Target: updated resource estimates for quantum attacks on ECDLP-256-based blockchain cryptography.
  • sources/2026-04-07-cloudflare-targets-2029-for-full-post-quantum-security — consumer-side canonical instance. Cloudflare's operational response to the Google disclosure — migration-target pull-forward to 2029 across the Cloudflare product suite, two-axis threat-model rewrite (HNDL + authentication), Mid-2026 ML-DSA / Mid-2027 Merkle Tree Certificates / 2029 full-PQ milestones. Demonstrates the pattern's intended industry-wide effect.
Last updated · 200 distilled / 1,178 read