跳到正文
原文
Google AI:DEV 作者专属(RSS)· ANIRUDDHA ADAK·· 11 小时前AI 评分50

Cryptotremor:一款测算加密何时真正失效的开源工具

Cryptotremor: finding out when your encryption actually stops working

AI 导读

Cryptotremor 是一款开源工具,粘贴加密清单后即可按算法给出量子对手破解所需的资源账本:RSA-2048 需 2,867 个逻辑量子比特、约 1.68 × 10⁸ 次非 Clifford 操作、距离-15 表面码下约 1.29M 物理量子比特。

正文

Every security team has the same question this October and almost nobody has the answer: when does the encryption in front of us actually stop working?

Not "someday". There is a date-shaped answer, and it is sooner than a 2035 deadline suggests.

RSA and elliptic-curve keys are not going to "break someday". Shor's algorithm factors a modulus in
polynomial time, so the thing that protects a captured TLS session today is the promise that you
will still care in ten years
. An adversary does not need a quantum computer to act on that promise
— they only need to store the traffic. That is harvest now, decrypt later, and it is already
happening.

So I built a survey instrument for it.

Live: https://cryptotremor.vercel.app
Source: https://github.com/aniruddhaadak80/cryptotremor

The rupture timeline

You paste a cryptographic manifest — or load the bundled reference estate — and Cryptotremor tells
you, per primitive, what a quantum adversary would actually have to build to break it.

The cost ledger is real arithmetic

For an RSA-2048 key the tool reports 2,867 logical qubits, ~1.68 × 10⁸ non-Clifford operations,
~1.29M physical qubits at a distance-15 surface code
.

The shape is grounded, not invented: a working register proportional to the modulus, a Toffoli count
superlinear in it, and 2·d² physical qubits per logical qubit. The coefficients are calibrated so
RSA-2048 lands in the same order as published factoring estimates (Gidney & Ekerå 2021 — 20M noisy
qubits, 8 hours; Gidney 2025 — ~1M noisy qubits, ~1 week). And symmetric crypto is not the
emergency: AES-256-GCM survives Grover at 128 bits, so it never ruptures inside the horizon, while
AES-128-GCM visibly does.

Asset detail with the quantum cost ledger

The part that surprised me

I expected the interesting output to be the rupture year. It usually isn't.

No cryptographically relevant quantum computer exists, so the year is a scenario. The tool reports
three throughput roadmaps side by side rather than one confident date. What it reports with
confidence is which constraint actually binds:

Binding constraint What it means
data-lifetime Your data must stay secret past the modelled break, so captured traffic becomes readable retroactively. Start now.
compliance NIST IR 8547's 2030/2035 milestone, or your migration lead time, runs out before capability does
capability The quantum computer genuinely is the limit — but your start date still decides the outcome

For most assets the binding constraint is the first one, and it binds today. That is the whole
argument for rotating now, and it has nothing to do with when the hardware arrives.

Each of six weighted factors carries the sentence that produced it and the lever that moves it. There
is no black-box score anywhere in the product.

The signature interaction: drag the horizon

The rupture scrub

The seismograph records, for each year, the share of the estate whose data would still be inside its
confidentiality window once the modelled break arrives. Drag the rail and the whole survey is
re-scored and persisted — that is a real PATCH writing to Postgres, not an animation:

Agent console

Grover is doing actual work here

A migration wave is a system, not a key: replacing one library retires every primitive that depends
on it. Picking the best system out of n candidates is exactly the unstructured search problem
Grover solves in O(√n) oracle calls, so each round runs one amplitude-amplification search, rotates
the winner out, and reports the measured probability gain over the uniform baseline. The
implementation is exact — uniform initial state, double precision, argmax as "measurement" — so the
same estate always yields the same wave order.

Why open matters here

The core of this product is open-source computation doing the actual reasoning: open
implementations of Grover search and Shor resource modelling, in TypeScript, that anyone can read,
audit and re-derive. There is no hosted model, no API key, no telemetry and no per-seat cost.

That was a deliberate choice over a "quantum AI" wrapper. The questions this tool answers are
arithmetic and policy, and an LLM in the loop would add nondeterminism to exactly the place where
determinism is the product. The engine is versioned (pq-survey-v1.0.0), total — it never throws on
unknown algorithms or nonsense manifests — and 82 tests assert it, including deterministic-repeat
and published SHA-384 known-answer vectors.

It runs on a laptop with no internet, and the same engine function serves the UI, the REST API, the
MCP tools and the exported report. There is no second implementation to drift.

An agent can drive it

Ten typed tools over MCP-style JSON-RPC 2.0. Mutations are idempotent — save_asset takes a key
backed by a unique index, and decisions and retirements are no-ops when already in the target state,
so a retried call cannot inflate the audit chain.

curl -sX POST https://cryptotremor.vercel.app/api/mcp \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05"}}' \
  | jq -r '.result.ownerToken'

The handshake returns an owner capability you pass back as x-ct-owner, so a stateless client keeps
its own estate. There are no accounts: a visitor owns a survey through 128 random bits in an HTTP-only
cookie, and every query is scoped by it.

Prove the record afterwards

Every create, update, decision and retirement appends an event whose SHA-384 seal covers the previous
seal plus the canonical JSON of the event. Editing any historical row breaks every later seal, so the
replay endpoint names the first broken link instead of returning a boolean. Deletions leave
tombstones, because a chain with a hole in it proves nothing.

That chain travels with the export. A partner opens a frozen snapshot without an account and gets
the per-asset ledger, the wave plan, feed provenance with retrieval times, and the chain head to
compare:

Partner report

Honest limitations

  • Rupture years are scenarios, not predictions. The report says so, and the safety disclaimer is in every export.
  • The rate limiter is an in-process map. On serverless it is a floor, not a guarantee; real limiting belongs at the edge.
  • Owner tokens are bearer credentials. Possession is ownership, at the same strength as the cookie.
  • The instrument has no proof of possession, so higher-assurance use needs signed attestation.

What I would love help with

The most valuable contribution is evidence: a better coefficient for Shor or Grover cost, tied
to a specific paper. Also a real manifest format (SPDX and CycloneDX crypto assets), or a compliance
regime I missed — cited to the primary document, not a summary.

If you work on post-quantum migration and disagree with a coefficient in src/lib/engine/quantum-cost.ts,
please open an issue. Being argued into a more accurate number is the best possible outcome.

git clone https://github.com/aniruddhaadak80/cryptotremor.git
cd cryptotremor && npm install && npm run dev

No environment variables required. Neon Postgres in production, embedded PGlite locally.

MIT licensed. Built for #hf26challenge — and for anyone whose data has to still be secret in 2040.

来源:Google AI:DEV 作者专属(RSS) · dev.to