fleetmesh
design note · FIPS 140-3 · § Identity · § Control plane
Evaluating fleetmesh operations within federal cryptographic frameworks: approved primitives, transport substitution, and perimeter gateway termination.
Implementation Architecture
Fleetmesh nodes interface with FIPS 140-3 environments using perimeter boundary gateways that terminate federal traffic through validated cryptographic modules.
Transport and envelope layers support NIST-approved algorithms, including Ed25519 (FIPS 186-5), P-256 ECDH, AES-256-GCM, and SHA-256. The base Nostr event signing layer uses secp256k1, which operates outside federal control perimeters on the mesh transport side.
Two distinct systems named FIPS
This document analyzes compliance with FIPS 140-3 (the United States federal benchmark for cryptographic security modules). It is distinct from Free Internetworking Peering System (FIPS), a decentralized routing overlay that utilizes Nostr public keys.
Compliance Scope
FIPS 140-3 certifies bounded cryptographic modules—hardware or software implementations tested by accredited Cryptographic Module Validation Program (CMVP) laboratories. The standard does not evaluate network protocol specifications. Practical compliance requires determining which algorithms run within the module boundary and how external security controls govern boundary traffic.
Three terms require distinction: a module is validated by NIST under CMVP; software is verified when third-party audits confirm compliant module integration; certified serves as commercial shorthand for validation. Calling non-approved algorithms from a validated library invalidates compliance.
Federal requirements typically derive from NIST SP 800-53 control SC-13 (applied via FedRAMP, FISMA, or CMMC). This control mandates approved cryptography specifically for protecting sensitive federal information, permitting external infrastructure to maintain native protocols outside the security perimeter.
Validation Timeline
FIPS 140-2 certificates transition to historical status in September 2026. Production implementations target FIPS 140-3 exclusively.
The inventory
The specification names few primitives. That makes the audit short. Each row ends in one of three states. Already approved. A substitute that costs nothing but a profile. No substitute at all.
| Where | What fleetmesh names | Status | What it would take |
|---|---|---|---|
| Node identity and every signature | secp256k1 · BIP-340 Schnorr | no The curve is not in SP 800-186. Schnorr is not in FIPS 186-5. That standard approves ECDSA and EdDSA and RSA. | Nothing. See the next section. |
transport key · iroh NodeId · libp2p PeerId |
Ed25519 | yes Approved by FIPS 186-5 since 2023. | Already compliant. Use a module whose certificate covers EdDSA. |
agreement key · DIDComm v2 ECDH-ES and ECDH-1PU |
X25519 | not yet The curve is in SP 800-186. The key agreement scheme is not yet in SP 800-56A. CMVP does not validate it today. | Swap for P-256 ECDH. DIDComm v2 registers the NIST curves for both envelope modes. This is a profile choice and not new protocol. |
| Grant and receipt envelopes · gift-wrapped control traffic | NIP-44 | no The ChaCha family is not an approved cipher in any construction. | AES-256-GCM under SP 800-38D. On the DIDComm plane that is a registered JWE choice. For kind 30801 and 30811 content it is a convention no NIP defines. It would need vectors of its own. |
Blinded addressable identifiers · blinding.kdf |
HKDF-SHA256 over an ECDH x-coordinate | tainted HKDF is approvable as the SP 800-56C two-step KDF. That holds only over a shared secret from an approved scheme. | Nothing in the KDF. The row is fixed by fixing the curve underneath it. |
| Commitments · receipt chain links · the protocol version digest | SHA-256 over canonical JSON | yes Approved. | Already compliant if the hash is taken inside a validated module. |
| Range reconciliation fingerprints | NIP-77 · SHA-256 truncated to 16 bytes | yes Approved. Protects nothing. | Already compliant. A fingerprint is a convergence check and not a security boundary. |
| Transport security | wss over TLS · iroh QUIC · libp2p | depends TLS 1.3 with AES-GCM is approvable. libp2p's Noise handshake is X25519 with ChaCha20-Poly1305 and is not. | Run TLS through a validated module. Drop the libp2p rung or run libp2p over its TLS transport. |
| Blinding factors | commitment.blinding_factor |
yes Fresh from a secure random generator per commitment. Never derived. Never reused. Unstated until this audit; the reference had been deriving it from the two public keys. | A profile names the SP 800-90A DRBG. The base now names the requirement. It needed that regardless of FIPS. |
| The reference implementation | ref/crypto.py |
no Pure Python. It says so itself: not constant-time and not for production key handling. | Nothing. It exists to be read and compared against. |
Two corrections the audit turned up
The ecosystem-bridges table described NIP-44 as XChaCha20-Poly1305. NIP-44 v2 is ChaCha20 with HMAC-SHA256 in encrypt-then-MAC. There is no extended nonce and no Poly1305. The distinction matters here. It decides which approved substitute a profile reaches for: an AEAD swap or an encrypt-then-MAC swap. It is also the kind of thing an assessor reads before the code. Fixed.
The second was worse. It was found only because the first question led to it. The
reference implementation derived the commitment's blinding factor as
SHA256("blind:" || issuer_pk || subject_pk). Anyone who can name the two
parties can compute that. A grant is mostly guessable from the tier ceilings. So a
derivable factor let a third party confirm a guess against the public commit
tag. The specification had said “32 random bytes” and nothing about where
they come from. It now does. The reference draws them from a secure generator.
Identity Primitives
In Nostr, public keys directly establish network identities. Event identifiers represent digests over canonical JSON serializations containing the author public key, verified by relays using BIP-340 Schnorr signatures over secp256k1. Replacing the identity curve breaks compatibility with the global relay mesh and DID resolution.
Deploying fleetmesh in regulated environments requires isolating native secp256k1 signatures to mesh transport boundaries while terminating external client connections with validated modules.
Deployment Architecture
Three deployment models accommodate federal security boundaries without breaking Nostr protocol compatibility:
OPTION A
Perimeter Gateway Isolation
A validated gateway terminates all federal incoming connections using approved FIPS 140-3 algorithms. Federal data terminates at the gateway, and outbound mesh messages follow established egress filtering rules. Internal mesh primitives operate strictly beyond the regulated perimeter.
Recommended — standard enterprise architectural boundary
OPTION B
Approved Cryptographic Profile
Nodes configure approved parameter choices: Ed25519 for wire transport, P-256 for DIDComm key agreement, AES-256-GCM for envelope encryption, and SP 800-90A DRBG for commitment blinding. Communicating nodes exchange approved cryptography across all layers except base event signatures.
Minimizes perimeter isolation requirements
OPTION C
Dual Approved Signatures
Nodes append a secondary ECDSA P-256 signature tag over the canonical event identifier. Federal relying parties verify the P-256 signature directly, while standard mesh relays continue verifying primary Schnorr signatures.
Used when federal auditors require end-to-end event verification
Profile Architecture
The protocol version declared by a node is a deterministic digest over kinds.json, messages.json, and constants.json. Adding specialized compliance definitions directly into base constants would alter version digests across the entire network.
The crypto block in constants.json establishes baseline primitives for all nodes: signature schemes, envelope ciphers, key agreement curves, transport keys, hashes, KDFs, and entropy sources.
Cryptographic profiles operate as local policy capabilities negotiated during DIDComm peering handshakes. Nodes declare capability flags and intersect supported envelope algorithms during session initiation:
{
"kind": 11801,
"tags": [
["protocol", "fleetmesh/0.1-draft", "6d8c8126a619e25c …"],
["c", "fips-140-3"] // queryable capability flag
]
}
propose.envelopes = ["jwe/a256gcm", "nip44/2"] // ordered by preference
offer.envelopes = ["nip44/2"] // empty intersection results in refusal
Peers lacking profile support peer normally using default parameters. Nodes negotiating the profile select mutual approved ciphers. If no shared cipher matches, the peering declines cleanly without protocol violations.
Specification Alignment
Cryptographic profiles represent local operator policy rather than global version revisions. Baseline cryptographic primitives remain defined in schema/constants.json.
Operational Constraints
Design reference for § Identity and § Control plane. For normative cryptographic definitions, see § Cryptographic identity and § Protocol governance.