QQUBBLE LABSSLATEWRAP · V1Open Qubble Chat →

◇ Qubble Labs · post-quantum research & engineering

Most of the internet
is being recorded today
to be decrypted later.

Harvest-now-decrypt-lateris not a hypothetical. The 2022 NSA memo, NIST's PQC standardisation timeline, and the volume of TLS captures sitting in nation-state storage are all in public record. The clock isn't the cryptanalysis — it's the provisioning of cryptographically relevant quantum hardware. The window between "not yet" and "already done" is the entire window we have to re-key the world.

Qubble Labs exists to build the surfaces that don't need re-keying.

◇ Not raising · not pre-selling · briefings by request


§ 01 · The shape of the threat

Every TLS handshake captured today is a future plaintext.

Shor
1994

Polynomial-time factoring + discrete log. Every public-key system that rests on those problems is on a deferred-execution timer.

NIST PQC
2024

ML-KEM, ML-DSA, SLH-DSA standardised (FIPS 203/204/205). Migration deadlines have started landing in federal procurement language.

Harvest window
Open

The captures are real and the storage is cheap. The migration of the existing stack is not on track to outrun the build-out of quantum hardware.

The serious post-quantum response so far is replace the asymmetric primitive with a lattice-based one and call it done. That moves the trust into a younger, less-attacked math problem and a new generation of side-channel surface. It is the right move for systems that need public-key key exchange. It is also not the only move.


§ 02 · A different bet

The cleanest defense against Shor's algorithm is not running it on anything.

Where the threat model permits, we remove the public-key surface entirely. We compose surfaces around primitives whose security degrades to a quantifiable Grover bound and stops there. The result has rougher edges in some places than a PKI-based system — and is unbreakable in places where PKI is not.

01 · Symmetric where possible

AES-256-GCM, HMAC, HKDF. Under Grover, 256-bit symmetric keys degrade to a 128-bit security level. That level remains beyond any feasible attack horizon for the foreseeable future.

02 · Out-of-band where required

Where two endpoints must share a secret, we move the exchange outside the network — URL fragments, QR codes, physical channels. Out-of-band key exchange has no Shor surface.

03 · Lattice where unavoidable

When public-key behaviour is genuinely required (and only then), we adopt NIST PQC primitives — ML-KEM and ML-DSA. We do not invent. We adopt slowly and audit obsessively.


§ 03 · A working demonstration

We made the case in code first.

Before publishing, we built one end-to-end surface that obeys the principles above. It is a small messaging app. It is not the point — the point is the principles — but it is the place where the principles meet a wallet, a browser, and a real adversary model.

cipherAES-256-GCM
KDFHKDF-SHA-256
forward secrecysymmetric one-way ratchet
key exchangenone · URL fragment, never on wire
quantum postureShor-immune by construction
server seesciphertext + length + routing
audit postureopen invitation, security@

Every message in the app exposes its ratchet step, IV, and key fingerprint in the UI. If a security property cannot be verified by the user, we do not claim it.

See the demonstration →

§ 04 · What we're building next

We're not going to announce it here.

The next surfaces extend the same principles into adjacent layers of the stack. We're reaching out to a small set of researchers, security operators, and partners who tend to recognize what we're building before it has a name. If you read this far and recognise the lineage of what's above — Bernstein, NIST PQC, Signal's ratchet, the Snowden harvest disclosures, NSA CNSA 2.0 — we want to send you the briefing.

◇ We are not raising. We are not pre-selling. We are not running a points program. The briefing list exists so that the people who would recognize what we're building know about it before everyone else.