Security¶

Identity¶

Every Salut instance generates a unique Ed25519 keypair on first launch. This keypair is stored in the Salut data directory and persists across restarts.

The keypair serves two purposes:

• Identity — the public key’s fingerprint uniquely identifies this machine to peers.

• Signing — handshake messages are signed to prove identity during pairing.

The identity is never transmitted in full. Only the fingerprint (a short hash of the public key) is shared during discovery.

Trust Model: TOFU¶

Salut uses Trust-On-First-Use (TOFU), the same model used by SSH. The first time you encounter a peer, you decide whether to trust it based on context (you recognize the machine name, you’re on your home network, etc.). Once trusted, the fingerprint is remembered.

If a peer’s fingerprint changes (which could indicate a different machine impersonating the original), the trust is invalidated and you’ll need to re-pair.

This model is pragmatic for local networks:

• No certificate authority to set up or manage

• No tokens to distribute (unless you want them — see Cluster Tokens)

• Trust decisions are explicit and visible in the UI

Encryption¶

Peer-to-peer communication uses TLS with self-signed certificates derived from each peer’s Ed25519 identity. This ensures:

• Confidentiality — activations and inference data are encrypted in transit.

• Integrity — data cannot be tampered with between peers.

• Authentication — the TLS certificate is bound to the peer’s identity key.

Since Salut peers verify each other by fingerprint (not by certificate chain), self-signed certificates provide the same security guarantees as CA-signed ones for this use case.

Pairing Handshake¶

When two peers pair, they perform a signed handshake:

1. Peer A sends a pairing request including its fingerprint.

2. Peer B verifies the fingerprint matches what it saw during mDNS discovery.

3. On acceptance, both sides sign a handshake message with their Ed25519 keys.

4. Each side verifies the other’s signature.

5. The trust relationship is recorded in the local database.

This ensures both peers are who they claim to be before any inference data flows.

Data Flow¶

Understanding what data moves where:

On your local network:

• mDNS advertisements (display name, port, GPU info, fingerprint) — visible to all devices on the network

• Inference requests and responses between paired peers — encrypted via TLS

• Model activations during distributed inference — encrypted via TLS

To the internet:

• Model downloads from Hugging Face (first use only, cached locally after)

• Nothing else — no telemetry, no analytics, no phone-home

Stored locally:

• Ed25519 identity keypair

• Peer trust database (fingerprints and trust states)

• Settings (JSON)

• Cached model weights (in Hugging Face cache directory)

API Key¶

The optional API key (configured in Settings) protects the HTTP API from unauthorized local clients. It does not affect peer-to-peer communication, which is secured by the fingerprint-based trust model.

When set, all API requests must include:

Authorization: Bearer your-api-key

This is useful when you want to restrict which local applications can query the inference API. Without an API key, any process on the machine (or network, if the port is reachable) can send requests.

Threat Model¶

Salut is designed for trusted local networks. It assumes:

• Your local network is not hostile (you trust the devices on it, or at least can identify them)

• Physical access to the machine implies full access (no attempt to protect against local root)

• The mDNS advertisement is inherently visible to all network participants

Salut does not protect against:

• Malicious devices on the same network that you accidentally pair with (but the pairing flow makes this a deliberate action)

• Network-level attacks from outside your LAN (don’t expose port 7258 to the internet)

• Compromise of the identity key (stored in plaintext in the data directory)

For multi-site or internet-facing deployments, consider running Salut behind a VPN or firewall.