End-to-end encryption, and how to check it
Every ShiftDesk session is encrypted from one computer to the other. This page explains what that covers, why not even our own server can read a session or slip into it, and how you can see it for yourself instead of taking our word for it.
What is encrypted
Everything a session carries travels inside one encrypted connection between the two computers: the picture, sound, mouse and keyboard, clipboard, chat and files. The keys are made fresh on the two computers for every session and never leave them; when the session ends they are thrown away.
- Directly between the computers. The connection runs from one computer to the other, not through our servers. On the same network it never leaves the building.
- A standard, well-tested protocol. The connection is DTLS, the encryption every browser uses for video calls (WebRTC), with a new key exchange for each session and authenticated encryption that also detects any change on the way.
- Relays see only noise. Where a network forces traffic through a relay, the relay passes on encrypted packets it has no key for.
Why we cannot look in
Our server introduces the two computers to each other. In doing so it passes on each computer's encryption fingerprint, so in theory a dishonest server could hand each side a fingerprint of its own and sit in the middle. ShiftDesk is built so that this fails, and fails visibly:
- The password checks the connection. With a password, both computers run a password-authenticated key exchange (CPace) over the encrypted connection, bound to the password and to both fingerprints. Anyone in the middle sees different fingerprints on each side, so the check fails and the session is refused.
- The password never travels. Neither the password nor anything it could be worked out from is sent; each attempt allows exactly one guess, and wrong passwords lock the source out for longer and longer.
- Without a password, a security code. When the other side is asked to accept, both screens show the same six-digit security code, worked out from the encrypted connection itself. If the codes match, nobody is in between.
- Signed updates. ShiftDesk only installs versions signed with our release key, so a tampered download is refused.
File transfer
Files sent from the File transfer window, dragged onto a session or copied and pasted between the two computers go through the same encrypted connection, on a channel of their own so they never hold up the picture. They are never stored on our servers.
- Checked on arrival. The sending computer works out a fingerprint of every file (BLAKE2b) and sends it along; the receiving one checks it before the file is kept, so a damaged or altered file is never mistaken for the real one.
- Only with permission. The other side decides whether files may be sent or taken at all, and can change it during the session.
Check it yourself
You do not have to trust this page. Each of these takes a few minutes:
- Compare the security code. Connect without the password so the other side has to accept. Both screens show a six-digit code; read them out to each other. The same code on both means the connection runs straight between the two of you.
- See where the session goes. Open the statistics in the session toolbar: the route shows LAN or P2P when the two computers talk directly.
- Look at the traffic. Run Wireshark on either computer during a session. You will see UDP packets going straight to the other computer's address, shown as DTLS "Application Data": unreadable. Besides that, only setup and account messages go to getshiftdesk.com, over a connection of their own.
- In the browser. When you connect from this website in Chrome, open chrome://webrtc-internals: it shows the DTLS connection, its cipher and the two addresses it runs between. The page's own code, including the password check, can be read in the browser's developer tools.
- Try to get in the middle. A connection with a wrong password, or one tampered with on the way, is refused before a single picture is shown.
What the server knows
To introduce computers and run accounts, the server knows some things about you, and we would rather say so plainly:
- Who, when and from where. Computer addresses, names and systems, account emails, the network address a computer connects from, and which address connected to which and when.
- Never the content. Nothing that is on a screen, typed, said, copied or sent as a file passes through the server.
- Saved passwords, if you save them to your account. A password saved in Saved computers while signed in is kept encrypted on our server so your other devices get it. If you would rather it stayed only on one computer, save the computer without its password, or use ShiftDesk signed out: then it is kept on that computer, sealed by Windows (DPAPI) or the macOS keychain.
- Letting your own computers in. Letting your account's computers in without asking is an option you switch on; it relies on your account. Leave it off if every session should need the password or a person to accept.
Technical summary
| Connection | WebRTC: DTLS 1.2, ECDHE key exchange (P-256), AES-GCM or ChaCha20-Poly1305; SCTP channels inside it |
| Password check | CPace on ristretto255 (libsodium), bound to the session, the password and both DTLS fingerprints; BLAKE2b |
| Without a password | The same exchange with no password; a six-digit security code from the shared key |
| Device identity | An Ed25519 key pair per computer, made on it; the private half never leaves it |
| Files | Their own channel in the same connection; BLAKE2b-256 checked on arrival |
| Passwords at rest | Windows DPAPI, macOS keychain; on Linux a file only your user can read |
| Updates | Ed25519 signatures, checked before anything is installed |
Next: How ShiftDesk works, from finding the other computer to a sharp picture, and the privacy policy.