What siepmu is

siepmu is an early-access messaging platform for organizations that cannot afford to lose a conversation to a future quantum computer. Defense and government teams handle traffic that must stay confidential for decades, and adversaries are already recording encrypted data today to decrypt it once the hardware arrives. siepmu is our answer: a messaging system whose cryptographic foundation is post-quantum from the first byte.

The design goal is a high-assurance platform suitable for air-gapped and tightly controlled networks, with role and clearance-based access control, multi-factor authentication, and a tamper-evident audit trail. It is built by the same team behind QNSQY and reuses our tested, KAT-verified post-quantum cryptography. It is not generally available. We are inviting a small number of teams to evaluate it under a briefing.

The cryptographic core Shipping core

The part of siepmu that exists, is implemented, and is covered by tests today is the crypto library, siepmu-core. It is the foundation everything else builds on, and it is the part we are most confident standing behind. It reuses QNSQY's NIST-conformant primitives rather than rolling new cryptography.

01

Hybrid Post-Quantum KEM

Session establishment uses ML-KEM-1024 (NIST FIPS 203) composed with classical X25519. Both must be broken to compromise a session, so a future quantum break alone is not enough.

02

ML-DSA-87 Message Signing

Messages and identity material are signed with ML-DSA-87 (NIST FIPS 204, Level 5), the highest-assurance lattice signature parameter set.

03

PQC Double Ratchet

A post-quantum Double Ratchet state machine derives a fresh key per message and re-keys with ML-KEM-1024 on an interval, so compromising one key does not unravel the conversation. Skipped-key limits cap memory use for out-of-order delivery.

04

Sender Keys for Groups

Large groups switch from per-member pairwise encryption to a sender-key construction, reducing per-message work from O(N) to O(1) while keeping the post-quantum envelope.

05

HKDF-SHA256 Key Schedule

Root, chain, and message keys are derived with HKDF-SHA256. Payloads are sealed with AES-256-GCM authenticated encryption; integrity is checked on every message.

06

Memory Hygiene

All key material implements zeroization on drop, constant-time comparisons guard secret-dependent branches, and process hardening disables core dumps so keys are not written to disk on a crash.

Verified The core ships with a startup self-test that checks AES-256-GCM (NIST SP 800-38D), HKDF-SHA256 (RFC 5869), and BLAKE3 against known test vectors, and is covered by 38 unit tests in siepmu-core. The underlying ML-KEM, ML-DSA, AES-GCM, and HKDF implementations are the same KAT-validated primitives used across QNSQY; see Security for the test-vector breakdown.

The platform around the core In development

siepmu is more than a library. The full platform pairs the crypto core with a relay, an API and identity service, a desktop client, file transfer, and voice. These components exist in the codebase and are progressing, but they are not production-ready and we will not claim otherwise. The list below is the design intent of a product in active development.

A

Role & Clearance-Based Access Core enforced

Access is gated by clearance level and compartment membership, with no-downgrade rules and fail-closed defaults: if a check cannot be performed, access is denied. The enforcement logic lives in the core and is unit-tested; the surrounding provisioning and admin surfaces are still being built.

B

TOTP Multi-Factor Auth In development

The identity service implements TOTP MFA (RFC 6238) with encrypted secrets and self-service enrollment, verification, and recovery flows. The auth service is maturing toward a hardened release; treat it as in development.

C

Relay Service In development

A WebSocket relay routes direct, group, and broadcast traffic between clients without reading message contents. The relay is partial and under active development, not a production deployment.

D

Encrypted File Transfer / Vault Roadmap

Chunked, authenticated file transfer is designed into the core wire format. End-to-end file vault workflows are on the roadmap and not yet ready for operational use.

E

Desktop Client & Voice Roadmap

A client with messaging, channels, contacts, and a voice path is in progress. The client and voice features are partial and in development; do not plan around them yet.

F

Tamper-Evident Audit In development

A hash-chained audit trail is designed for clearance, key-lifecycle, and message events. Audit primitives exist in the core; the operator-facing review tooling is being built out.

Design principles

These are the goals we are building toward. We are publishing them so you can hold the finished product to them.

Post-quantum from the first byte. Hybrid NIST FIPS 203/204/205 algorithms (ML-KEM-1024, ML-DSA-87) composed with classical X25519/Ed25519, so a break in either family alone is not enough.
Designed for air-gapped deployment. The architecture targets high-assurance, isolated networks. Air-gapped operation is a design goal of the platform in development, validated per-deployment, not a blanket guarantee today.
Fail-closed by default. When an access or integrity check cannot be completed, the operation is refused rather than allowed.
Standards, not obscurity. Built on publicly reviewed NIST and IETF standards and on QNSQY's existing KAT-validated crypto, not proprietary algorithms.
Honest about maturity. We separate what ships from what is planned, and we will tell you exactly where a given component stands when you ask.

Status and honesty

siepmu uses NIST-standardized post-quantum algorithms (FIPS 203/204/205); it is not FIPS 140-3 / CMVP validated, and that validation is on the roadmap, not claimed. The cryptographic core (siepmu-core) is implemented and unit-tested; the relay, API/identity service, file vault, desktop client, and voice are partial and in active development and should not be treated as production-ready. siepmu is offered as early access by request, not as a generally available product. We do not reference specific customers, contracts, or deployments. For the current state of any component, ask us directly.

siepmu