-
-
Source-linked evidence. Each finding carries a file, line, rule version, and SHA-256 span hash for review before prioritization.
-
Safe refusal. Endpoint testing is rejected before DNS or network I/O unless a literal loopback host and authorization are present.
-
Frozen-gold evaluation. The release records 11 true positives, zero false positives, zero misses, and no unsupported high-confidence claims.
-
Measured local canary. Classical X25519 and hybrid X25519MLKEM768 negotiate only on loopback with synthetic ephemeral keys.
-
Compatibility before rollout. Current and OQS reference clients succeed; a constrained X25519-only client fails as expected.
-
Human assumptions stay visible. Retention, ownership, exposure, and dates drive separate confidentiality and authenticity priorities.
-
Bounded inventory. KeyShift maps classical assumptions across 12 synthetic fintech services and flags unsupported Rust instead of guessing.
-
Rollback-ready plan. Every phase names an owner, cohort, measure, fallback, rollback, and retirement gate with cited evidence.
Inspiration
Small fintech teams cannot migrate cryptographic assumptions they cannot find. Long-lived financial records can also create urgency before standards, client support, and operating plans are ready. KeyShift began with a practical question: how can a small team turn that uncertainty into a reviewable rehearsal without claiming that an experimental local result makes production quantum-safe?
What it does
KeyShift scans a bounded set of supported Go, JavaScript, lockfile, and TLS configuration evidence without executing target code. Every finding points back to a file, line, rule version, and SHA-256 span hash. Human-supplied retention, ownership, exposure, and transition assumptions remain visible instead of being invented by the scanner.
The team can then run a controlled, loopback-only TLS canary. KeyShift records classical X25519 and hybrid X25519MLKEM768 negotiation, compares current, OQS reference, and intentionally constrained clients, measures the local run, and exports a phased migration plan with owners, cohorts, success measures, fallbacks, rollback triggers, and retirement gates.
How we built it
The product is a Go application with embedded browser assets and versioned local evidence. Go AST and goja-based parsing identify supported source patterns; strict configuration, bounded paths, skipped symlinks, and length-limited snippets keep the scan non-executing and reviewable. Unknown or unsupported coverage becomes an explicit warning rather than a cryptographic guess.
The canary uses a digest-pinned Docker image and reference oqs-provider environment. Its
classical and hybrid endpoints bind only to 127.0.0.1, run with synthetic ephemeral keys
inside a mode-0700 tmpfs, and are removed by exact container and network name. Host OpenSSL,
the OQS reference client, and a constrained X25519-only client produce a compatibility
matrix that preserves both success and expected failure.
Playwright and axe-core cover the judge workflow and accessibility. Remotion, FFmpeg, and Qwen3-TTS produce the captioned demo from real product footage. The release stores raw measurements and a frozen-gold evaluation alongside the generated migration plan.
Challenges
The hardest boundary was separating library capability from observed runtime behavior. Negotiating a named group does not prove which provider supplied it, establish standards conformance, or make the surrounding application production-ready. KeyShift preserves the exact runtime evidence while keeping those stronger claims out.
Automation also had to stop safely. Endpoint probes require a literal authorized target and are rejected before DNS or network I/O otherwise. The scanner cannot expand CIDRs, ranges, or wildcards, and the canary must tear down even after a failed client check.
Accomplishments
Release run KSR-0D2E7068FD found all 11 supported gold findings across a synthetic
12-service fintech: 11 true positives, zero false positives, zero misses, and zero
unsupported high-confidence claims. One Rust fixture was explicitly marked unsupported.
The current OpenSSL client and OQS reference client both completed the hybrid rehearsal, while the constrained X25519-only client failed against the hybrid-only endpoint as expected. The run recorded 1,084 classical and 3,351 hybrid handshake bytes, eight measured successes per endpoint after two warmups, exact environment context, and a migration plan that passed all ten deterministic plan checks.
What we learned
Post-quantum migration is not a one-line algorithm swap. It is an evidence and coordination problem: teams need to know where assumptions live, which retained data creates urgency, which clients will fail, how success is measured, and how to roll back without hiding uncertainty.
We also learned that expected incompatibility is valuable evidence. A clearly recorded constrained-client failure gives a migration owner more information than a demo that shows only the happy path.
What's next
Next steps are additional bounded language and configuration adapters, standards-status updates as the hybrid group evolves, and a consenting pilot that supplies literal authorized test endpoints. Production work would also add organization authentication, hardware and provider-specific test plans, and change-review integration. The local rehearsal will remain separate from certification, compliance, and production authorization.
Log in or sign up for Devpost to join the conversation.