End-to-end encryption
Retyc uses end-to-end encryption (E2EE) based on age, a modern, audited standard designed to replace PGP.
General principle
End-to-end encryption means your files are encrypted on your device before being sent, and decrypted on the recipient's device after download. At no point do Retyc's servers see the content in plain text.
Sender Retyc servers Recipient
────── ───────────── ─────────
Plaintext file
↓ encryption (age)
Encrypted file ───────────→ Encrypted storage ────────→ Encrypted file
↓ decryption (age)
Plaintext file
How does the encryption work?
Asymmetric keys
Each Retyc user has a key pair:
- Public key: stored on Retyc's servers, shared with senders
- Private key: stored encrypted on Retyc's servers, never accessible in plain text by Retyc
These keys are hybrid identities (see Post-quantum resistance below).
Transfer process
For every transfer, Retyc generates a dedicated session key, never reusing your personal keys to encrypt the files themselves:
- The sender generates a session key pair (an ephemeral identity, specific to this transfer)
- The files are encrypted with the session public key (data encryption via ChaCha20-Poly1305)
- The session private key is encrypted (wrapped) with the public key of each authorized recipient
- If a password is set, the session private key is also wrapped with a key derived from that password
- Encrypted files and wrapped keys are sent to Retyc's servers
- The recipient unlocks the session private key with their private key (or the password), then decrypts the files
Keys never travel in plain text.
Unlocking the private key
Your private key is stored encrypted on Retyc's servers, protected by your passphrase. It is only decrypted locally, in your browser, when you enter your passphrase.
The passphrase protects the private key via scrypt (N=2^18), a costly derivation run in your browser. Retyc never knows your passphrase or your private key in plain text.
Post-quantum resistance
Retyc identities are hybrid by default: they combine X25519 (classic elliptic curve) and ML-KEM-768 (a post-quantum key encapsulation mechanism, FIPS 203), through an extension of the age format (keys in the age1pq1… format).
The goal of this hybrid approach is to reduce the risk that a weakness affecting a single component could by itself compromise data confidentiality: it would take both a mathematical breakthrough against X25519 and a weakness in ML-KEM-768. It notably targets the harvest now, decrypt later strategy, where encrypted data is captured today in the hope of decrypting it with a future quantum computer.
For technical details (primitives, derivations, wrapping scheme), see the Retyc white paper.
Why age?
age is a file encryption format designed by Filippo Valsorda (former Go team at Google). Its advantages:
- Simple, well-audited specification
- No complex cryptographic configuration (no risk of misconfiguration)
- Modern algorithms: X25519 and ML-KEM-768 for key exchange, ChaCha20-Poly1305 for data encryption
- Open-source reference implementation
What Retyc cannot do
Thanks to end-to-end encryption:
- Retyc cannot read the content of your files
- Retyc cannot recover your files if you lose your passphrase
- Even if Retyc's servers are compromised, the files remain encrypted and unreadable