End-to-end encryption without the jargon
Everyone says their app is encrypted. Few explain what that actually means — or why it matters. We break down exactly how File Yeet protects your files.
"Encrypted" has become a marketing word. It appears on product pages, in privacy policies, and in app store descriptions, usually without explanation. The word does a lot of work to make you feel safe without telling you much.
There's a meaningful difference between "encrypted in transit" and "end-to-end encrypted," and most apps only offer the former. Here's what each actually means, and what File Yeet does.
Encrypted in transit vs. end-to-end encrypted
Encrypted in transit means the connection between your device and the server is encrypted. An attacker on your local network can't see your file. But the server can. The server decrypts your data, stores it, and re-encrypts it when serving it to the recipient. This is how Dropbox, Google Drive, and most cloud services work. The company holds the keys.
End-to-end encryption (E2EE) means only the sender and recipient hold the keys. Not the app developer. Not the server operator. Not a court order served to the company. The data is encrypted before it leaves your device and decrypted only on the recipient's device. A server in the middle — if one exists at all — sees only scrambled bytes it cannot read.
File Yeet is end-to-end encrypted. Every transfer, every time.
How it works in practice
File Yeet uses QUIC as its transport layer, and QUIC is always TLS 1.3 encrypted. But that alone would only give you encrypted-in-transit. The E2EE property comes from how File Yeet establishes connections.
When two File Yeet users connect, they perform a Diffie-Hellman key exchange — a mathematical operation that lets both parties independently derive the same shared secret without ever transmitting that secret over the network. An eavesdropper who intercepts the entire exchange cannot compute the key.
The shared secret is then used to derive a session key for AES-256-GCM encryption. AES-256 is the same standard used by governments, militaries, and financial institutions. GCM mode means the encryption is also authenticated — any tampering with the ciphertext is detected and rejected. You can't decrypt corrupted data, and you can't silently replace encrypted data with something else.
What about the relay?
When two devices can't establish a direct connection, File Yeet falls back to a relay server. This might sound like a cloud middleman, but the encryption model is unchanged.
The relay routes packets between two peers. It does not participate in the key exchange. It has no access to the session key. It sees the same thing an attacker on the path would see: encrypted bytes with no way to decrypt them.
Concretely: the relay knows that device A and device B are talking, and roughly how much data is flowing. It does not know the file name, the file contents, or anything else about the transfer. This is true even if the relay server is compromised.
Why AES-256 and not something newer?
AES-256 is not the flashiest choice, but it's the right one. It's been studied intensively for over two decades. No practical attacks exist against a correctly implemented AES-256-GCM cipher. It's hardware-accelerated on every modern processor — Intel and ARM both ship dedicated AES instructions, which is part of why File Yeet transfers are fast even when encrypting large files.
Some newer constructions like ChaCha20-Poly1305 are excellent alternatives, particularly on devices without hardware AES acceleration. iroh, the underlying library we use, handles cipher negotiation automatically — devices that benefit from ChaCha20 will use it.
What we can't protect against
Honesty matters here. End-to-end encryption protects data in transit and from server-side access. It does not protect against:
- A compromised device. If the recipient's device has malware, it can read the file after decryption. Encryption stops at the device boundary.
- A malicious contact. File Yeet encrypts the channel, but it doesn't control what someone does with a file once they have it.
- Metadata. We know when transfers happen and between which accounts. We don't know what's being sent, but the fact that a transfer occurred is visible to us.
No system is unconditionally secure, and anyone claiming otherwise is selling something. What File Yeet does guarantee is that the file contents transit the network readable only by you and the person you chose to send to. That's the meaningful security property for file transfer, and it's the one we've built first.