Skip to content

Security & Encryption

The link between your phone and your desktop is end-to-end encrypted. The relay that carries it is a byte forwarder that cannot decrypt anything. This page explains how that holds up, and is equally clear about what it does not cover.

Your desktop usually sits behind a router that will not accept inbound connections, and a phone moves between networks constantly. So neither device listens for the other. Both dial outward to a relay, which pairs the two connections and forwards bytes between them.

The relay is a rendezvous point, not a participant. The encryption is negotiated directly between your phone and your desktop, inside the tunnel the relay forwards.

StageProtocol
PairingNoise IKpsk0 over Curve25519, ChaCha20-Poly1305, BLAKE2s, using the single-use pairing token as a pre-shared key
Ongoing sessionsNoise KK over Curve25519, with the desktop as initiator
Message framingA secretstream construction that detects truncation, reordering, and replay
Push payloadsXChaCha20-Poly1305, sealed to your device’s key

Session keys are re-negotiated roughly every two minutes, following WireGuard’s rekey interval. That bounds how much traffic a single compromised key could ever expose, and it means recovering from a key compromise does not require re-pairing.

Pairing ends with a six-digit code derived from the handshake transcript, shown on both devices. Comparing it is what makes a machine-in-the-middle on the relay detectable: an attacker who intercepted the exchange would produce different digits on each side. See Pairing a Phone.

  • On the phone, pairing keys and trust anchors live in hardware-backed secure storage: the Keychain on iOS, the Android Keystore on Android.
  • On the desktop, the device identity is encrypted with your operating system’s secure storage. If that is unavailable, Kangentic refuses to persist the keys rather than writing them unprotected, which is why pairing is disabled on a system without it.

Content is encrypted, but carrying it still involves infrastructure that observes something. Whoever operates the relay you use, including Kangentic when you use the hosted one, can still see the IP addresses of both peers, the timing of every connect and reconnect, frame sizes and frequency, and which two connections were paired together.

The Hosted Relay states that disclosure in full for the instance Kangentic runs, including the two parts specific to how it is deployed. This is inherent to operating any relay rather than a property of this one.

The practical mitigations are: run your own relay, which removes Kangentic from the picture entirely; single-use pairing tokens; and the relay’s own per-IP and per-slot rate limits and connection caps, so only paired devices can consume relay capacity at all.

The guarantee is structural rather than a promise. The relay routes purely on an opaque slot identifier in the connection URL and forwards every binary message byte for byte, and its source has no runtime dependency on the end-to-end crypto package at all, which a test enforces. The blind-relay guarantee covers the mechanism, and Relay Security Model states each claim with the test that pins it.

A paired phone is granted ten capabilities, and shell access, file reads, and arbitrary command execution are not among them because those verbs do not exist in the protocol at all. This matters more than a permission toggle would: there is no code path to abuse, so a compromised phone or a flaw in the pairing flow still cannot turn into command execution on your desktop.

Use GitHub’s private vulnerability reporting on the relevant repository, or email hello@kangentic.com with “SECURITY” in the subject line.

See also:

Kangentic is free and open source. A star helps other people find it.

Star on GitHub