Pairing
The Mac advertises itself on the local network while sharing is on. Each iPhone gets its own 32-byte pairing key, which the Mac shows as a grouped code while that iPhone is being paired, and which you type once on it. That key becomes a TLS pre-shared key: both ends derive the connection from those bytes independently, so a wrong code produces no shared secret at all and the connection dies inside the handshake, before a single byte of your prompt is read.
The key is stored in each device's keychain, marked so that it does not sync to other devices and does not travel in a backup. It is never logged. A key is never shared between phones: anyone holding a key can derive every session key under it, so a shared one would let one phone pose as your Mac to another. The Mac keeps one per phone, and removing a phone deletes its key.
Why there is a second layer
A pre-shared key authenticates well but, on its own, does not make the connection forward secret: every session's keys descend from the same pairing key, so anyone who later obtains that key could decrypt traffic they had recorded earlier. The TLS version that would fix this does not work with an external pre-shared key on this platform — we have measured that twice, a year apart.
So forward secrecy comes from inside the tunnel instead. Every connection performs its own HPKE key exchange (RFC 9180), and each frame after it is sealed under keys derived from that exchange. The ephemeral private key never leaves memory and is discarded with the connection. An attacker who records your traffic, then obtains your pairing key a year later, strips the outer layer and finds an encapsulation they cannot open.
Post-quantum
XWingMLKEM768X25519
A hybrid of X25519 and ML-KEM-768. Secure as long as either half is.
X25519 is the classical algorithm in widespread use today; ML-KEM-768 is the lattice-based standard chosen to resist a quantum computer. Recorded traffic therefore stays unreadable even to an adversary who stores it now and waits for hardware that does not exist yet.
We use HPKE rather than a hand-rolled exchange because composition is the part that goes wrong. Its pre-shared mode cannot be combined with X-Wing, so the pairing key is mixed into the session's keys afterwards instead, the way TLS 1.3 combines a pre-shared key with a fresh exchange. A session therefore opens only between the two devices holding that pairing, whatever happens to the layer outside it.
We checked that with the ProVerif protocol verifier, with the network wholly in an attacker's hands. The session stays secret and both sides agree on what was said. That holds even with X-Wing broken outright, and the conversation stays sealed if the pairing key is stolen later. The one thing such a theft exposes is the phone's name, which it sends before the Mac has proved itself.
No infrastructure of ours
The phone reaches the Mac directly — on your local network, or at whatever address you choose to point it at. There is no relay, no rendezvous server and no account, so there is no list of your devices held anywhere, including by us. Discovery on a local network uses the operating system's own service discovery; nothing about it is reported outward.
The practical consequence is that reaching your Mac from outside your own network is something you arrange — most simply by pointing the address at your Mac through a VPN you run. We think that is the right trade: the alternative is putting a company in the middle of your traffic in exchange for convenience.
What this does not protect against
Stating the limits is part of the claim being worth anything.
The Mac reads your prompt
It has to, in order to answer. Offload means your data goes to a second machine you own; it does not mean it goes nowhere.
A compromised device
If either machine is already controlled by someone else, no transport security helps.
The code while you move it
Anyone who can read the code off the Mac's screen as you type it can pose as your phone. Pair where you would type a password.
Traffic volume and timing
The contents are sealed; that two devices are talking, and roughly how much, is visible to anyone watching the network.
Reporting a vulnerability
Write to security@elythros.com. Please include enough detail to reproduce the issue. We will acknowledge within 72 hours, and we will not take legal action against anyone who reports a problem in good faith and gives us a reasonable chance to fix it before describing it publicly.
For what the app sends and stores more generally, see the privacy policy.