ftlsatcom

ftlsatcom is an experimental end-to-end encrypted chat protocol whose transport is a satellite-like packet relay. The included simulator behaves like the satellite: clients register an address, then it forwards opaque UDP datagrams to one node or broadcasts them to every other registered node. Encryption and message assembly happen only at the endpoints.

This repository is a local research environment. It does not contain a radio/SDR implementation and must not be used to transmit through a real satellite without authorization and compliance with the relevant spectrum, network, and satellite-service rules.

What is implemented

• XChaCha20-Poly1305 authenticated encryption using libsodium. Each message gets a fresh random nonce.
• Password-based key derivation and deterministic node IDs derived from human-readable names.
• A versioned binary packet format with source/destination IDs, message ID, timestamp, fragment position, length, and CRC-32 checksums.
• Fragmentation into 200-byte payloads and ordered, duplicate-safe, out-of-order reassembly.
• Authentication of message routing metadata as AEAD associated data.
• A replay window that ignores fragments from recently completed messages.
• A UDP satellite simulator with directed and broadcast forwarding plus optional latency, loss, and duplication.
• Unit and loopback integration tests for encryption, corruption detection, packet management, and satellite routing.

The wire format and encryption envelope are project-specific, but the cryptographic primitive is deliberately not custom-built. Designing a new cipher would make the application less secure; the application-specific work lives in key derivation, authenticated metadata, packetization, and reassembly.

Dependencies

• A C++17 compiler
• make
• pkg-config
• libsodium

On macOS with Homebrew:

brew install libsodium pkg-config

On Debian or Ubuntu:

sudo apt install build-essential pkg-config libsodium-dev

Build and test

make
make test

The build produces:

• ftlsat: interactive endpoint client
• satellite_sim: local satellite relay
• ftlsat_tests: test binary, built by make test

Local test environment

Start the satellite in one terminal:

./satellite_sim

Start Bob before sending directed traffic, so the relay learns Bob's address:

./ftlsat --name bob --to alice

Then start Alice in another terminal. Enter the same shared password in both clients:

./ftlsat --name alice --to bob

Use --to broadcast (the default) to send to all registered nodes. Type /quit to stop a client.

Passwords can be supplied with --password for scripted local tests, but prompting is preferable because command-line arguments may be visible to other local processes.

Simulating a less reliable link

The simulator accepts controlled link impairments:

./satellite_sim --latency-ms 250 --drop-rate 0.05 --duplicate-rate 0.10

Rates are probabilities from 0 to 1. The application tolerates packet reordering and duplication. Packet loss is exposed intentionally for testing; retransmission/ACK support is not yet part of protocol version 1, so dropping any fragment prevents that message from completing.

Run ./satellite_sim --help and ./ftlsat --help for all options.

Packet layout (protocol version 1)

Each UDP datagram contains a 48-byte header followed by at most 200 payload bytes. Multi-byte integers use network byte order.

Offset	Size	Field
0	4	Magic (FTLS)
4	1	Protocol version
5	1	Packet type (HELLO or DATA)
6	2	Flags
8	4	Source node ID
12	4	Destination node ID
16	8	Message ID
24	8	Unix timestamp in milliseconds
32	2	Fragment index
34	2	Fragment count
36	2	Payload length
38	2	Reserved
40	4	Payload CRC-32
44	4	Header CRC-32
48	0–200	Payload

CRC detects accidental corruption before reassembly. It is not a security mechanism; XChaCha20-Poly1305 authenticates the encrypted content and logical routing metadata end to end.

Current scope

The simulator provides the router behavior needed to develop the protocol locally. A future radio adapter can replace SatComManager while keeping the packet, reassembly, and crypto layers. Reliability across packet loss, identity/key exchange, persisted contacts, and SDR/modem integration remain separate next steps.