Post-quantum on every connection. Verify it on the wire.
Conflux 1.0.0-pre is the third generation of VeilNet's overlay: ML-KEM key establishment and ML-DSA identity on every connection, adopted as one architecture pattern across cloud, data centre, edge and disconnected sites.
Each connection logs the key exchange it negotiated, so the property can be checked on a running node, not only in a design document.
- Key exchange
- SecP384r1MLKEM1024, TLS 1.3 hybrid group
- End-to-end seal
- ML-KEM-1024 with AES-256-GCM
- Node identity
- ML-DSA-87, proven by a signature bound to each session
- Session keys
- Ephemeral, rotated every ten minutes
- Negotiation
- None. One parameter set per realm tree, fixed at genesis, so there is no downgrade path
- Standards
- NIST FIPS 203 (ML-KEM) · FIPS 204 (ML-DSA)
Category 3 realms use X25519MLKEM768 and ML-DSA-65.
The flows that carry harvest-now-decrypt-later exposure, and the control that removes it
Data in transit: customer, payment, citizen, classified and operational data that crosses services, clouds, sites and partners, and has to stay confidential for years after it is captured.
VeilNet removes that exposure with post-quantum key establishment and identity on every connection, as one overlay instead of one TLS stack at a time. It complements your cryptographic inventory and PKI work; it doesn't replace them.
Milestones sit at the end of the year each source names. NIST's draft IR 8547 also deprecates 112-bit RSA and elliptic-curve algorithms after 2030 and disallows them after 2035.SourcesUS EO 14412EU roadmapUK NCSCASDITSM.40.001NIST IR 8547
It fits the trust model, PKI and segmentation you already run
Each organisation runs its own realm tree. A Guardian you host holds the realm root key and signs every credential locally, and every node verifies admission from that signed credential chain for itself. Policy is centrally defined in Guardian and enforced locally at every endpoint.
Read the VeilNet architecture →- Segmentation
Sub-realms are cryptographic tenant boundaries. Compartment labels segment nodes within a realm.
Anchor · Realms and credentials → - Access policy
Centrally defined in Guardian and enforced locally at every endpoint.
Architecture · Control and data → - Key custody
Guardian, self-hosted in your own cloud account, data centre or disconnected site, holds the realm root key and signs every credential locally.
Architecture · Where the tree is rooted → - Resilience and third-party risk
No gateway, vendor cloud or coordination server in the traffic path. Established nodes keep connecting if the control plane is unreachable.
Architecture · A network with no centre → - Revocation
A member holding the block power signs a block, which spreads through the realm's knowledge from member to member and needs nothing from the blocked node. It can be lifted. Credential expiry remains the permanent removal.
Anchor · Expiry and blocks → - Restricted environments
Guardian runs with no outbound network access, so classified, OT and remote sites don't depend on an external service.
Guardian · Deployment →
Hold the design up to your own threat model
The protocol, its handshake and its parameter sets are documented in full, including what it doesn't promise. Read them before you talk to us. When you do, it's with the engineers who wrote it.
| Layer | Mechanism | Standard |
|---|---|---|
| Transport key exchange | TLS 1.3 hybrid group, SecP384r1MLKEM1024 by default | FIPS 203, hybrid with P-384 |
| End-to-end seal | ML-KEM sealing with AES-256-GCM, end to end between nodes | FIPS 203 |
| Node identity | ML-DSA-87 identity on every node, proven with a signature bound to each session | FIPS 204 |
| Session keys | Ephemeral, rotated every ten minutes | Anchor protocol |
| Algorithm selection | One parameter set per realm tree, fixed at genesis. The protocol does not negotiate algorithms, so there is no downgrade path | Anchor protocol |
| Evidence | Each connection logs the key exchange it negotiated | Per-connection log |
NIST FIPS 203 and 204 algorithms; Guardian's identity layer runs Keycloak in strict FIPS mode. Category 3 realms use X25519MLKEM768 and ML-DSA-65.
See it working in your own environment
The pre-release joins your machines to a realm VeilNet hosts, so there is nothing to stand up first. Put two machines on it, then watch the traffic between them with your own packet capture to see it work.
What you download is Conflux, the node agent. It installs Anchor, the protocol that runs on every node, renews its credential and runs it as a service.
The pre-release, on our hosted realm
$ sudo conflux up
IPv4 [e.g. 10.128.0.7/24, blank for none]: 10.128.0.1/24
Minted a taint for this network:
brhk-2mq9-tzva-6pjs-k4xe-nw7d-qf
anchor anchor6btpa3gn6w4stipba4hekzho7caw6srfyy5puvbz7mfanaiept5a
overlay fd80:c4b9:99ae:4411:c531:fd4f:754f:f08a/48
ipv4 10.128.0.1/24
interface anchor0
taint brhk-2mq9-tzva-6pjs-k4xe-nw7d-qf
credential valid until 2026-10-06T06:35:43Z (29d 23h)
service active (systemd: conflux.service, enabled at boot)$ sudo conflux up --taint brhk-2mq9-tzva-6pjs-k4xe-nw7d-qf
A reboot needs nothing typed: the service is registered, the credential renews itself, and the machine comes back at the same overlay address.
The full evaluation kit, under your own root
When you engage us for a full evaluation, you run the network under a root you hold, in your own environment.
- Stand up a GuardianIn your own cloud account, data centre or disconnected site. It holds the realm root key.Guardian · Getting started →
- Create a realmIts parameter set is fixed at genesis and holds for the whole tree.Guardian · Realms →
- Commission test nodesEach node holds its own ML-DSA-87 identity and a credential your Guardian signed.Guardian · Commissioning a node →
- Check what each connection negotiatedEach connection logs the key exchange it used.Anchor · Post-quantum, on every connection →
Download 1.0.0-pre
seven builds, across five operating systems. Check the download against the checksums, then see install notes for the right platform.
- Linuxx86-64conflux-linux-amd64
- LinuxARM64conflux-linux-arm64
- macOSApple siliconconflux-darwin-arm64
- Windowsx86-64conflux-windows-amd64.exe
- WindowsARM64conflux-windows-arm64.exe
- FreeBSDx86-64conflux-freebsd-amd64
- OpenBSDx86-64conflux-openbsd-amd64
Every link points at the 1.0.0-pre release, where each new build of this line is published, with its SHA256SUMS. A machine on an earlier build moves onto a new one by replacing the binary and running conflux start.
Operate it, and evidence it to your auditors
Guardian is the part you run in production and put in front of your accreditors. Its deployment, sign-in, renewal, revocation and observability are documented for the people who will operate it.
Read the guardian stack →Guardian runs with no outbound network access, built for accreditation against US DoD, Australian ISM and UK baselines.
Guardian · Deployment →Guardian ships with a compliance register that maps its controls to NIST SP 800-53, ready to sit in your evidence pack.
Ask for it with an evaluation →Audit records on a dedicated volume, ready for your SIEM pipeline. Each connection logs the key exchange it negotiated.
Guardian · Observability →Guardian's identity layer runs Keycloak in strict FIPS mode.
Guardian · Sign-in and roles →Telemetry is exported over OpenTelemetry, down to each individual flow, into the collector and observability stack you already run. Operations and security teams see the overlay in the same place as everything else.
Guardian · Observability →Bring your threat model to the people who wrote the protocol.
Tell us which flows concern you and where they run. We'll scope an evaluation with you, starting with a free PQC exposure study of your data in transit. No sales sequence.
Already running the build? Use the second tab to tell us what turned up. It goes straight to the people who wrote it.
Or write to sovereign@veilnet.net