// encryption
Reticulum uses cryptographic identities as the basis for addresses, encryption and authentication. For most users that mainly means: messages are encrypted before they leave your device, and intermediate nodes only see ciphertext.
A Reticulum identity is a 64-byte private keyset. The two halves have different roles and are not used interchangeably.
| Bytes | Purpose | Algorithm |
|---|---|---|
| 0-31 | Key agreement (encryption) | X25519 |
| 32-63 | Signing (signatures) | Ed25519 |
The private key file is a bearer credential: whoever has it can act as that identity. There is no recovery server or central registry that can restore or revoke it. Lose it and that identity is gone.
Reticulum routes on 16-byte destination hashes. A hash is public address material, not a password. For Single destinations the hash is derived from the application destination name and the public-key hash of the identity.
In practice that means:
The 128-bit address space is deliberately kept short. A packet is at most 500 bytes, and on low-bandwidth links you want to spend as little of that as possible on addresses. For practical use, 128 bits is plenty.
For Single destinations the sender can encrypt a packet without a network round trip if it already knows the public key or current ratchet key from an announce.
| Step | Action |
|---|---|
| 1 | Generate fresh ephemeral X25519 key material |
| 2 | Derive a shared secret with the destination public key or ratchet key |
| 3 | Derive symmetric encryption and authentication keys with HKDF |
| 4 | Encrypt the payload and authenticate the ciphertext |
| 5 | Add the ephemeral public key so the recipient can derive the same secret |
Every packet uses fresh ephemeral key material. If a packet fails authentication, it is dropped before application code sees it.
Links provide forward secrecy through their own ephemeral key exchange. The link initiator and destination exchange fresh key material during link establishment and derive session keys for that link. Those keys are not the long-term identity keys and are not reused for later links.
That is why you use a link for larger or stateful transfers. After setup it works efficiently, and the initiator does not have to reveal a long-term identity unless the application chooses to.
Ratchets provide forward secrecy for link-less Single destination packets. When a destination has ratchets enabled, the announces contain a rotating X25519 ratchet public key, signed by the long-term identity. Senders that know the current ratchet encrypt to it instead of to the static identity key. When old ratchet private keys are discarded, previously intercepted packets become harder to decrypt, even if the long-term identity is compromised later.
| Parameter | Default |
|---|---|
| Generated ratchets retained | 512 |
| Minimum rotation interval | 1800 seconds |
| Received ratchet expiry time | ~30 days |
The retention window exists because announces need time to propagate. Peers may still encrypt to a recent ratchet until they learn the newest one.
| Function | Primitive |
|---|---|
| Signatures | Ed25519 |
| Key exchange | X25519 (ECDH) |
| Key derivation | HKDF |
| Encryption | AES-256-CBC with PKCS7 |
| Authentication | HMAC-SHA-256 |
| Hashing | SHA-256, SHA-512 |
The Python reference implementation uses PyCA/OpenSSL. Ratspeak's Rust implementation uses Rust crypto crates. The two are wire compatible. See architecture for how routing and addressing work, and LXMF for the messaging layer.
Encryption stops intermediaries from reading messages. It does not stop someone from sending unwanted encrypted messages to a public destination. LXMF adds spam resistance with stamps and tickets.
| Mechanism | How it works |
|---|---|
| Stamp | Proof-of-work token attached to an LXMF message. Unknown senders have to put in CPU work to produce a stamp that meets the recipient's advertised cost. |
| Ticket | Per-sender token that lets a trusted correspondent skip the stamp work for future messages. |