Post-Quantum Cryptography — Live at the Governance Layer.
mnnr.app already markets ML-KEM-768 and ML-DSA. This page is where the claim becomes a public artifact — real ML-KEM-768 + ML-DSA-65 keys, a cryptographically-signed genesis attestation, and verifier recipes you can run yourself. Honest about what is live and what is roadmap.
Signed 2026-06-14T06:30:00Z by ML-DSA-65 key with SHA-256 fingerprint 610991c4…328bc984:
“mnnr.app cryptographic infrastructure is live and operational as of this date. ML-KEM-768 (FIPS 203) + ML-DSA-65 (FIPS 204) application keys are published, the genesis attestation file is signed, the Cloudflare X25519MLKEM768 hybrid TLS edge is active, and the A50 Emergency Retrofit SKU is open through 2026-07-15.”
Note added 2026-07-26: the text above is quoted from the signed canonical bytes and cannot be altered without invalidating the signature. The engagement window it references closed on 2026-07-15 and is not currently open. The attestation also binds issuer.formation_date as 2025-02-26; the corrected date is 2025-02-27 per Wyoming SoS filing 2025-001622999, and it will be carried in the next attestation version. Neither item affects the cryptographic statements, which remain independently verifiable — run the verifier below.
Full keys: /crypto/mnnr_mldsa65_public.key (fingerprint 610991c4…), /crypto/mnnr_mlkem768_public.key (fingerprint e4ee6a12…). A detached countersignature from an offline ceremony is not yet published; when it is, it will appear here as a named artifact. The fingerprints, key files, and genesis attestation already on this page are independently verifiable today.
What is live verifiable now
Four artifacts a third party can validate without trusting our word: the TLS edge, the ML-DSA-65 application key, the ML-KEM-768 application key, and the signed genesis attestation declaring all of the above.
| Status | Algorithm | Issued | SHA-256 fingerprint | Audit archive |
|---|---|---|---|---|
| ACTIVE | ML-KEM-768 | 2026-06-09 | e4ee6a1219ea5565c80874fa4196706c2c58301e5f8f95ca7034652dd0aaa6ac | archive → |
| ACTIVE | ML-DSA-65 | 2026-06-09 | 610991c46a97c4ab94e6c785345abbcd51e2d9ce24dcb2e256b8ac76328bc984 | archive → |
| REVOKED | ML-KEM-768 | 2026-06-08 | e5fbccc68b4f7464187f98fea47571808e1edf9c3979ba3004f2dc75380e60fa | archive → |
| REVOKED | ML-DSA-65 | 2026-06-08 | 4ecb7ee3894447d96e11b732c559851e1073c926a248ed1df13f1fdc8722cde9 | archive → |
Full key files (raw public keys + signed attestations) live in the audit archive with a per-file SHA-256 manifest at FINGERPRINTS.md. Active keys remain inline below for direct hybrid-TLS verification by partners.
mnnr.app is served from Cloudflare Pages. Cloudflare enabled the X25519MLKEM768 post-quantum hybrid key exchange across its edge during 2024 and it is on by default for Pages projects. Clients with Chrome 124+, Firefox 132+, or curl ≥ 8.10 negotiate the hybrid automatically; older clients fall back to classical X25519.
Self-attestation from this server: TLS 1.3 is live and the connection upgrades to the PQ hybrid when the client supports it. The build-time probe in this session used curl 7.81 / OpenSSL 3.0.2, which is below the PQ-capable threshold and therefore reports only classical X25519 — that is an artifact of the probe client, not of the server. Run a modern client to observe the hybrid negotiation directly.
2 · Application key — ML-DSA-65 live
3 · Application key — ML-KEM-768 live
4 · Genesis attestation signed
issuer.veteran_status value in the signed object below reads "Decorated disabled veteran-owned". MNNR no longer asserts "Decorated" — the DD-214 records the National Defense Service Medal and marksmanship qualification badges, which are service and qualification awards rather than personal decorations. The claim MNNR makes is "Veteran-owned". The signed bytes are left unaltered because editing them would invalidate the ML-DSA-65 signature; the value is corrected in the next attestation version.issuer.formation_date value in the signed object below reads "2025-02-26". The Wyoming Secretary of State filing record for MNNR LLC (Filing ID 2025-001622999) shows a filing date of 2025-02-27 12:05 PM with no delayed effective date, and under W.S. § 17-29-201(e)(i) a Wyoming limited liability company is formed when its articles of organization become effective. The correct formation date is 2025-02-27, and every unsigned surface on this site has been corrected to match. The signed bytes are left unaltered because editing them would invalidate the ML-DSA-65 signature; the value is corrected in the next attestation version.{
"algorithms": {
"hash": "SHA3-256 / SHA-256 for fingerprints",
"kem": "ML-KEM-768 (NIST FIPS 203)",
"signature": "ML-DSA-65 (NIST FIPS 204)"
},
"attestation_version": "1.2",
"canonicalization_rule": "JSON canonicalization: sorted keys, no whitespace, UTF-8; sign the canonical bytes directly",
"custody": "Genesis private keys held by MNNR LLC as sole custodian; stored on a non-synced local path (C:\\ProgramData\\mnnr_oursly_pq_keys\\) with NTFS ACL restricting read/write to MNNR LLC authorized principal + SYSTEM only. HSM custody migration remains on the roadmap.",
"issued_at": "2026-07-12T20:07:53.613Z",
"issued_at_utc": "2026-06-10T06:37:25+00:00",
"issuer": {
"ein": "33-3678186",
"formation_date": "2025-02-26",
"founder": "MNNR LLC",
"jurisdiction": "Wyoming, USA (domestic)",
"legal_entity": "MNNR LLC",
"principal_place_of_business": "Silicon Hills, California, USA",
"veteran_status": "Decorated disabled veteran-owned"
},
"key_id": "mnnr-genesis-2026-06-09",
"library": "@noble/post-quantum (FIPS 203 ML-KEM-768, FIPS 204 ML-DSA-65, final standards)",
"product": "mnnr.app",
"public_keys": {
"ml_dsa65_sha256": "610991c46a97c4ab94e6c785345abbcd51e2d9ce24dcb2e256b8ac76328bc984",
"ml_kem768_sha256": "e4ee6a1219ea5565c80874fa4196706c2c58301e5f8f95ca7034652dd0aaa6ac"
},
"purpose": "Governance-layer policy verdicts, key exchange for governance API, audit-log streaming.",
"rotation": {
"deprecated_artifacts_preserved_at": "/crypto/mnnr_mldsa65_public.key_DEPRECATED_20260608.* and /crypto/mnnr_mlkem768_public.key_DEPRECATED_20260608.* (audit-trail preservation; verifiers may still reproduce the prior fingerprints from these files to confirm the rotation).",
"deprecated_fingerprints": {
"ml_dsa_65_sha256": "4ecb7ee3894447d96e11b732c559851e1073c926a248ed1df13f1fdc8722cde9",
"ml_kem_768_sha256": "e5fbccc68b4f7464187f98fea47571808e1edf9c3979ba3004f2dc75380e60fa"
},
"rotated_on_utc": "2026-06-10T06:37:25+00:00",
"rotation_reason": "The initial 2026-06-08 genesis keys were generated into a cloud-synced OneDrive folder, creating a custody mismatch: the root-of-trust private keys were exposed to Microsoft OneDrive cloud storage rather than held exclusively on a local non-synced path. Treating the 2026-06-08 keys as compromised and rotating to fresh keypairs.",
"supersedes_key_id": "mnnr-genesis-2026-06-08"
},
"scope_live_tonight": [
"Public ML-KEM-768 key published with SHA-256 fingerprint",
"Public ML-DSA-65 key published with SHA-256 fingerprint",
"This genesis attestation, signed with the ML-DSA-65 private key",
"TLS edge: Cloudflare X25519MLKEM768 hybrid (per Cloudflare default for Pages)"
],
"scope_roadmap_not_live_tonight": [
"ML-DSA-signed policy verdict bus (Q3 2026)",
"ML-KEM-768 key-wrapped policy delivery (Q3 2026)",
"PQ-attested audit log streaming for BaFin / federal procurement (Q3 2026)"
],
"supersedes": {
"archived_at": "crypto/archive/",
"attestation_version": "1.1",
"ml_dsa65_public_key_sha256": "2992fe6051b860627bf33be529e4303bf8256136953fa948cea7b10f292b81f2",
"ml_kem768_public_key_sha256": "18aa839f406940090c41e2a02441fc410cc89cbfca680cc34e9f64d83b5ed71a",
"reason": "Previous genesis signature did not verify against the published ML-DSA-65 public key under FIPS 204; keys rotated and attestation re-issued with the final-standard implementation."
}
}
Verify it yourself
Three reproducible recipes. All three operate on the public artifacts above; none of them require trusting this page.
Recipe 1 — Python (cross-platform · verified end-to-end 2026-06-16)
Tested on Windows 11 + Python 3.14 the night this page shipped. Identical recipe works on macOS + Linux. Returns mnnr genesis attestation: VERIFIED in under 10 seconds.
Step 1 — install the library (all platforms): pip install pqcrypto
Step 2a — Windows PowerShell (one paste, runs immediately):
@'
import base64, json, urllib.request
from pqcrypto.sign import ml_dsa_65
UA = "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"
def fetch(url):
req = urllib.request.Request(url, headers={"User-Agent": UA})
return urllib.request.urlopen(req).read()
attest = json.loads(fetch("https://mnnr.app/crypto/mnnr_genesis_attestation.canonical.json"))
canon = json.dumps(attest, sort_keys=True, separators=(",", ":")).encode()
pk = base64.b64decode(fetch("https://mnnr.app/crypto/mnnr_mldsa65_public.key.b64.txt"))
sig = base64.b64decode(fetch("https://mnnr.app/crypto/mnnr_genesis_attestation.sig.b64"))
ml_dsa_65.verify(pk, canon, sig)
print("mnnr genesis attestation: VERIFIED")
'@ | Out-File -Encoding utf8 "$env:TEMP\verify_mnnr.py"; py "$env:TEMP\verify_mnnr.py"
Step 2b — macOS / Linux bash:
python3 - <<'PY'
import base64, json, urllib.request
from pqcrypto.sign import ml_dsa_65
UA = "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36"
def fetch(url):
req = urllib.request.Request(url, headers={"User-Agent": UA})
return urllib.request.urlopen(req).read()
attest = json.loads(fetch("https://mnnr.app/crypto/mnnr_genesis_attestation.canonical.json"))
canon = json.dumps(attest, sort_keys=True, separators=(",", ":")).encode()
pk = base64.b64decode(fetch("https://mnnr.app/crypto/mnnr_mldsa65_public.key.b64.txt"))
sig = base64.b64decode(fetch("https://mnnr.app/crypto/mnnr_genesis_attestation.sig.b64"))
ml_dsa_65.verify(pk, canon, sig)
print("mnnr genesis attestation: VERIFIED")
PY
Expected output (success): mnnr genesis attestation: VERIFIED
Expected output (tampered / wrong key): pqcrypto.sign.ml_dsa_65.VerificationError
Library version pin: pqcrypto 0.4.0. Other liboqs / PQClean bindings expose the same FIPS-204 primitives under different module names. The User-Agent header is required because Cloudflare’s WAF blocks the default Python-urllib/3.x identifier on this origin — a browser-like UA is the simplest workaround.
Recipe 2 — Fingerprint check (no PQ library required)
# confirm the published ML-DSA-65 public key matches the fingerprint curl -sS https://mnnr.app/crypto/mnnr_mldsa65_public.key | sha256sum # expected: 610991c46a97c4ab94e6c785345abbcd51e2d9ce24dcb2e256b8ac76328bc984 # confirm the ML-KEM-768 public key matches the fingerprint curl -sS https://mnnr.app/crypto/mnnr_mlkem768_public.key | sha256sum # expected: e4ee6a1219ea5565c80874fa4196706c2c58301e5f8f95ca7034652dd0aaa6ac
If either fingerprint diverges from the value above, the keys have been rotated or tampered with — verify against the canonical genesis attestation before trusting the new value.
Recipe 3 — TLS hybrid probe (modern client required)
# curl 8.10+ with a recent OpenSSL/wolfSSL/BoringSSL build, or use Chrome 124+ curl --verbose --tls13-ciphers TLS_AES_256_GCM_SHA384 https://mnnr.app 2>&1 \ | grep -iE "named_group|key_share|MLKEM"
In Chrome: chrome://flags#enable-tls13-kyber must be Enabled (default true since 124). Inspect a request in DevTools → Security → Connection — look for "X25519MLKEM768" in the key exchange.
What is roadmap — not live Q3 2026
The bullets below are deliberately not on the "live" list above. The mnnr.app marketing pages will not claim them as live until the artifacts are publishable here and verifiable by a third party.
Application-layer integrations (Q3 2026 target)
- ML-DSA-65–signed policy verdict busEvery policy verdict the governance API returns will carry an ML-DSA-65 signature chained back to this genesis key — verifiable offline by any policy consumer.
- ML-KEM-768 key-wrapped policy deliveryPolicy bundles delivered to enrolled tenants will be wrapped under per-tenant ML-KEM-768 ciphertexts derived from this KEM key, so policy contents are confidential against intermediaries.
- PQ-attested audit log streaming for supervisory and federal-procurement reviewThe append-only audit ledger will emit signed batches — the same ML-DSA-65 primitive, batched and timestamped — exportable to BigQuery / Snowflake / Postgres for supervisory review.
Why this matters
Q-day is a moving target — but harvest-now-decrypt-later is happening today. An adversary recording your TLS traffic and your audit-log payloads in 2026 only needs to decrypt them in 2035 to extract the same value. Migrating to a quantum-safe key exchange now closes the window retroactively for traffic that, by then, has been retired from memory but not from intercept logs.
CNSA 2.0 sets the federal trajectory. The NSA's Commercial National Security Algorithm Suite 2.0 mandates ML-KEM and ML-DSA across new National Security Systems, with first deadlines as early as 2025 for new development and full migration by 2030–2033. Federal procurement that touches NSS will inherit those deadlines through the contract chain.
Audit-log unforgeability has a ten-year horizon. Long-retention audit logs need to be cryptographically verifiable for the full statutory retention window. The audit trail you sign in 2026 must still be unforgeable in 2035. Signing on classical RSA / ECDSA today is the premature decision.
Trust anchor
MNNR LLC
Wyoming domestic LLC · EIN 33-3678186 · formed 2025-02-27.
Founder: MNNR LLC. Principal place of business: Silicon Hills, California.
Genesis key custody: The four private keys backing the published public keys are cold-stored offline under founder custody pending institutional HSM transition. HSM-custody migration is scheduled Q3 2026; the rotation plan will be published on this page under a versioned anchor (a supersession note) at the moment of cutover. The historical custody record as of 2026-06-09 is preserved verbatim in the signed genesis-attestation JSON below for audit-chain integrity.
Operational status as of 2026-06-21: ML-DSA-65 + ML-KEM-768 signing material is held in cold storage with access restricted to founder. HSM/KMS evaluation is in progress (AWS CloudHSM, Google Cloud HSM, and Thales Luna under review for PQC algorithm support, multi-party ceremony, and disaster-recovery escrow). Algorithm choice (NIST FIPS 203/204) is independent of custody posture — the cryptographic primitives in use are standardized, while the operational custody control is currently founder-operated pending institutional transition.
Library used to generate the genesis keys: @noble/post-quantum (as recorded in the signed v1.2 attestation above; the superseded v1.1 record credited pqcrypto 0.4.0 and did not verify). ML-KEM-768 is implemented per NIST FIPS 203; ML-DSA-65 per NIST FIPS 204. Canonical JSON for the attestation: sorted keys, no whitespace, UTF-8.
Veteran-owned