How traffic is encrypted

Every tunnel is encrypted end to end between the two devices. Keys are generated on the device and never leave it, and the cipher suite is fixed rather than negotiated.

SXAccess encrypts traffic directly between the two devices that are talking. The tunnel uses one fixed, modern cipher suite - ChaCha20 for encryption, Poly1305 for authentication, Curve25519 for key exchange, BLAKE2s for hashing. Nothing is negotiated at connection time, so there is no weaker option for an attacker to force the two ends down to.

No component in the middle can read your traffic. The management service distributes public keys and access rules, the Discovery service forwards messages sealed to the far device's key, and a relay - when one is needed - forwards ciphertext it holds no key for. Traffic to a resource behind a routing device leaves the tunnel at that device and travels the last stretch inside its network as ordinary traffic.

Division of labour

Handled by the tunnel	Added by the SXAccess agent and services
An encrypted tunnel between two known public keys	Knowing which devices exist, and what their current public keys and endpoints are
Packet handling in the kernel on Linux, in user space everywhere else	NAT traversal, so the two endpoints can find each other without port forwarding
Cryptographic routing (a key maps to an allowed source range)	Access rules, so the allowed ranges reflect who may reach what, and a packet filter for the ports and protocols a rule allows
Silent, stateless behaviour on the wire	Enrolment, session expiry, revocation, and a record of changes under Activity

Keys never leave the machine

The agent generates its key pair locally the first time it runs. The private key stays in the agent's own state on the device and is never transmitted - the management service only ever receives the public key. A device keeps its key until it is enrolled again; there is no other way to give it a new one.

Because cryptographic routing binds a public key to an allowed source range, a device that is not in your network map cannot inject packets into your interface even if it learns your address. Access control is enforced by the tunnel itself and by the agent's packet filter, which applies the ports and protocols your access rules allow - not by a firewall rule you have to remember to write.

Optional pre-shared key

A pre-shared key adds a symmetric secret on top of the key exchange. Devices that use one only connect to devices that hold the same key, so set the same key on all the devices that must reach each other, or on none of them. The iOS and Android apps set it under Settings → Advanced → Pre-shared key, and the CLI agent takes it through --preshared-key, a support-level option. The macOS and Windows apps cannot set one, so a device with a pre-shared key cannot connect to a Mac or PC that runs the app.

Kernel and user space

Only the CLI agent on Linux runs the tunnel in the kernel, using the kernel's own tunnel module when the kernel has one. The CLI agent on macOS and every app - macOS, Windows, iOS and Android - run the tunnel in user space. Both paths speak the same protocol with the same keys, so devices on either path connect to each other as usual.

To see which path a device uses, run sxaccess info -d and read the Interface row: Kernel or Userspace.

Messages to the services are sealed too

The agent talks to the management service over TLS, and each message is additionally sealed with NaCl box (Curve25519, XSalsa20 and Poly1305) between the device's key and the service's key. Negotiation messages that pass through Discovery are sealed with NaCl box to the far device's key, so Discovery forwards what it cannot read. The connection to a relay runs over TLS, and the relay only accepts an agent that presents a token issued by the management service.

Quantum resistance, optionally

Quantum resistance adds a post-quantum key exchange on top of the tunnel's own handshake, rather than in place of it. It is experimental and only the CLI agent has it: you turn it on with an option of sxaccess start, and the apps do not support it. A device that turns it on then connects only to devices that use it too.

To keep reaching every other device, the apps included, also turn on its permissive mode, a second option of sxaccess start that still accepts devices without quantum resistance. sxaccess start --help lists both options. On a connected device, start changes nothing, so use sxaccess stop && sxaccess start --<flag>, with the options in place of --<flag>. Run it as one line: a connection that goes through SXAccess, such as an SSH session to this machine, drops until start has finished. It does not work in a session opened with sxaccess shell: stopping the agent closes that session and ends the command, so use the console or an OpenSSH session. sxaccess info -d shows the state in the Quantum res. row, which reads on (permissive) when both are on.