Files
fips/docs
Johnathan Corgan d7a1a24706 Clear the connection's key slots, erase the handshake keypair in place, and document what is now cleared
Option::take moves a value out but writes only the None marker, so the
old bytes stay in the slot. Completing a handshake left the whole
handshake state, the node's long-term private key and the ephemeral key
included, in the connection's handshake slot, which on a peer machine
is heap memory that outlives the handshake, and take_session left both
traffic keys of the session in the session slot.

Add clear_slot in the noise module: it drops whatever the slot holds,
overwrites every byte of the slot with zeros through zeroize's volatile
flat-type erase, and leaves None. complete_handshake takes and unwraps
the handshake first and then clears the slot, so a release build copies
the handshake once, as before, and then zeroes the slot; clearing inside
the take had cost a second stack copy that nothing cleared.
take_cleared, built on clear_slot, takes the value out and clears the
slot, and take_session uses it, since there the session goes straight
to the caller and no extra copy appears.

start_handshake and receive_handshake_init hold the node's long-term
keypair across early returns, so a guard erases it on every exit. The
guard owned a copy: building it copied the keypair into a temporary and
then moved it into the guard's binding, and only the binding was erased.
On the early-return paths nothing reused the temporary's stack slot, so
a copy of the long-term private key stayed in the frame. The guard now
borrows the caller's binding and erases it where it lies when dropped,
so making or moving it copies no key bytes.

Tests cover what safe code can observe: the value comes out intact and
is dropped exactly once, the slot is None and reusable, a type whose
all-zero bytes would read as Some still ends as None, a handshake and
session taken this way still interoperate, and a guard held across an
early and a normal return erases the caller's own keypair on both. The
clearing itself is shown by a release build's disassembly and a scan of
process memory, not by a unit test.

The security reference now says the SHA-256 and HMAC states clear
themselves on drop and that a completed handshake and a session taken for
a rekey leave their slot cleared, and names what is still left: the copies
stack moves leave, the session keys or unfinished handshake that stay in a
control machine's heap memory when the whole connection state is moved off
it on promotion or reaping, and the copies of the private key that loading
the identity from a secret string leaves in that constructor's frame, now a
known limit. It also no longer says each erase is a volatile write followed
by a compiler fence: only secp256k1's erase uses a fence, zeroize's follows
the write with an empty asm! optimisation barrier, and in both it is the
volatile write that keeps the store.
2026-10-01 22:41:14 +00:00
..
2026-09-29 00:01:53 +00:00
2026-08-30 10:42:59 +00:00

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.