Johnathan Corgan
af67aae5fa
The security reference had no account of key clearing; the only one was in the v0.4.2 release notes and changelog, and it rested on reading the source. Add a "Key Material in Memory" section measured against an x86_64 release build instead. Every erase in the Noise handshake and identity code that the daemon links is present as stores in the generated code. What the erases do not reach is stated concretely: the copies a move leaves behind (a handshake state is built on the stack and moved several times, taking a completed handshake out of its connection slot leaves its full contents, the long-term private key included, in heap memory, and a completed session is moved into the session slot and taking it out leaves both traffic keys there), registers and spilled temporaries, and library state the daemon cannot clear. The SHA-256 and HKDF states are cleared on drop by an opt-in zeroize feature of sha2 0.11 and hmac 0.13 that the daemon does not yet enable; ring's LessSafeKey offers no way to clear its cached key; libsecp256k1 clears its own signing nonce and secret scalar on a best-effort basis, but the daemon cannot clear the library's internals. A completed session keeps an uncleared copy of the handshake hash on purpose, since nothing derives a key from it and the session hands it out. The doc comments on Identity, ErasingKeypair, Drop for HandshakeState and NoiseSession said the compiler "may duplicate or move the bytes to places no code here can name". They now say what a release build shows: the erases are kept, and the copies they miss are the ones moves leave behind, such as the intermediate Identity that from_secret_str builds and copies into its Result, left in that constructor's frame, and the contents a take leaves in a connection's handshake or session slot.
FIPS Documentation
FIPS (Free Internetworking Peering System) is a self-organizing encrypted mesh network built on Nostr identities, capable of operating over arbitrary transports — local networks, the public internet, Tor, Bluetooth, or point-to-point links — without central infrastructure.
With FIPS, your machine becomes a node in the mesh with a self-generated cryptographic identity. There are two ways to deploy it.
As an overlay on top of existing IP networks, FIPS lets your node reach any other FIPS node wherever it sits — behind a NAT, on a different ISP, on a phone over cellular, on a laptop with only Bluetooth in range, or behind a Tor onion. The mesh forwards IPv6 traffic transparently and end-to-end encrypted, with no central VPN concentrator or coordinating server.
From the ground up over raw Ethernet, WiFi, or Bluetooth, FIPS provides a complete permissionless network without any pre-existing IP infrastructure, ISP, or DNS. Any node that joins the link gets routable IPv6 addresses, peer discovery, and a path to every other node automatically.
Either way, existing networking software runs over it unchanged: SSH, HTTP servers, file transfer, anything IPv6-native works the same way it would on a local network.
New to FIPS? Start with the Getting Started guide.
Documentation Sections
Tutorials
If you are starting from scratch and want a guided path to a working mesh, go here.
How-To Guides
If you have a specific task in mind — enabling a feature, deploying a component, diagnosing a problem — go here.
Reference
If you need to look up wire formats, configuration keys, command flags, or counter inventories, go here.
Design
If you want to understand how the mesh self-organizes, why FIPS makes the choices it does, or how the pieces fit together, go here.
Releases
If you want the notes for a particular version — what changed, what broke, and what to do about it on upgrade — go here.