Security

This page explains what protects your files, and what does not. The name of each method is given in parentheses for the curious.

In short

• No account, no server run by the project, no telemetry.
• Everything Tressyl sends between your devices is end-to-end encrypted: only your own devices can read it.
• Tressyl does not encrypt the files on your disks. Use your system’s disk encryption for that (for example BitLocker on Windows, LUKS on Linux).

One identity, keys that stay on the device

• Your identity has one root key. It is sealed by your passphrase (Argon2id, ChaCha20-Poly1305), so the passphrase is needed to add a device, remove one, or change what your devices sync.
• The passphrase has at least 15 characters. The app measures its strength as you type, and can suggest one made of 6 words picked at random.
• Each device creates its own key, which never leaves it. On a computer, Tressyl protects it with the system’s keyring when there is one (Secret Service on Linux, Credential Manager on Windows).
• The always-on node never holds the root key.

Adding a device

• The device you add it from shows a 10-character code. The code works once, for one attempt, and for 10 minutes at most.
• The code is never sent over the network. Both devices use it to prove to each other that they know it (SPAKE2): someone watching the exchange cannot test guesses afterwards.
• The invitation you can copy to the new device holds only the address of the other device, never the code.

Connections

• Devices are addressed by their key, never by a machine name.
• Connections use TLS 1.3 over QUIC, with a hybrid key exchange (X25519 + ML-KEM-768) and no fallback to a classic one.
• Each device proves, inside the connection, that it holds a certificate signed by your root key. A device of another user is never accepted.
• A relay, if you run one, only passes encrypted traffic along. The discovery service publishes which relay a device uses, never its IP addresses. Both are reached over HTTPS only.

A lost or stolen device

• You remove it from another of your devices. The removal is signed, spreads from device to device, and closes the connections to the removed device at once.
• A device kept away from your informed devices does not learn it was removed. To bound that risk, each device stops exchanging files when it has gone 7 days without a recent proof of the current device list (a “stamp”). A removed device that never hears of its removal can therefore sync for 7 more days at most.
• The files already on the stolen device stay there: Tressyl cannot erase them remotely. Disk encryption protects them.

The 7-day rule in everyday use

The stamp comes from a device with the stamper role: your first device, by default, renews it every day. If no stamper is on for more than 7 days, your other devices pause their sync until one can be reached.

If you run an always-on Linux node, make it a stamper, so that your identity does not depend on one laptop. This is done with a command described in the node’s deployment guide; the app does not offer it yet.

Post-quantum

Traffic recorded today could be decrypted later by a quantum computer. Tressyl’s key exchange and signatures each pair a classic method with a post-quantum one, so the protection holds as long as either method holds. See What does “post-quantum” mean here?

What to keep in mind

• Tressyl has not been audited by a third party yet.
• It is built on established components rather than its own: iroh for the connections, rustls and aws-lc-rs for the encryption.
• It is pre-release software. Keep your own backups.

Reporting a vulnerability

A private channel for security reports will be published with the first public release. Until then, there is no public way to report one.