Security
How tunnl. works
Only someone with the link can read your message. Not even us.
In four steps
- Write. You type your message and attach files if you like.
- Encrypt – in your browser. Before anything leaves your device, your browser turns it into unreadable gibberish. It creates the matching key itself, at random.
- Share the link. You get a link. The key is inside it, after the # sign. Browsers never send that part to a server.
- Open – and gone. The recipient opens the link and their browser decrypts the message. The first message can be opened only once, then its content is deleted. If you like, you keep writing confidentially in the same conversation.
Why it is secure
The key stays with you
It is created in your browser and only exists in the link. The server never sees it – not even in its logs.
We only store gibberish
Messages, files and file names are stored on the server encrypted only. Anyone breaking in finds nothing readable.
Read once, deleted
The first message is gone once opened. With the same applies to replies and attachments. Whoever finds the link later is too late.
Password as a second lock
Optional. It is only used in the browser and never transmitted. After 10 wrong attempts the conversation deletes itself.
No IP addresses
We slow down abuse with one-way values that change daily instead of stored IP addresses. No tracking, no ads.
No third-party code
Encryption uses your browser's built-in Web Crypto API. The site loads no scripts from third parties – a strict security policy enforces that.
What the server knows – and what it doesn't
| The server knows | The server doesn't know |
|---|---|
| encrypted messages and files | the content |
| size, number and time of messages | file names |
| whether something was read and when it expires | the key and the password |
| a check value to verify access | who is involved – as long as you write without an account |
Encryption in detail
For those who want to know exactly. Everything runs in the browser using standard methods also used by banks and messengers.
Key and link
- The browser creates a random key S of 256 bits. That is more possibilities than there are atoms on Earth.
- With a password, it is additionally stretched with PBKDF2-SHA-256 and 600,000 rounds. That makes systematic guessing extremely slow.
- From both, HKDF-SHA-256 derives a master key – and from that two separate values:
- the content key for AES-256-GCM,
- an access proof. The server only stores a SHA-256 hash of it. The content key cannot be computed from the access proof.
- The link looks like this:
tunnl.ch/k#id.r1.key– everything important after the #.
That is how the server can detect a wrong password without knowing the password: the access proof then doesn't match the stored hash.
Messages
Every message is encrypted with AES-256-GCM and a fresh random value (IV). GCM also checks authenticity: if even a single bit is changed, the browser refuses to decrypt.
Files and images
Every file gets its own random key and is encrypted in chunks, even very large files. Each chunk is bound to its number and a “last chunk” flag. Swapped, missing or truncated chunks are detected immediately.
Account
Your account key is created in your browser and stays there. The list of your conversations is encrypted with it before it is stored. For a new device there is the recovery code (160 bits of randomness) or a passkey. We store your e-mail address encrypted.
Echo to the tunnl. team
Echoes are sealed with the team's public key (ECDH P-256). Only the team account can open them in its browser – the server cannot.
Quantum computers
The worry is “harvest now, decrypt later”: someone collects encrypted data and waits until a quantum computer can open it. That mainly threatens public-key methods – RSA and the curves nearly every key exchange on the net relies on. Shor's algorithm breaks them once the machine is large enough.
tunnl. encrypts content purely symmetrically (AES-256-GCM, HKDF-SHA-256). No asymmetric key exchange vulnerable to Shor's algorithm is involved in protecting the content – the key travels in the link, not through a negotiation. By today's understanding tunnl. is therefore quantum-safe, with no migration to post-quantum algorithms ever needed.
Grover's algorithm, which attacks symmetric keys, leaves room too: it halves the strength, turning 256 bits into an effective 128. That is still considered out of reach.
Two places do use public keys (ECDH P-256): the inbox for contacts and the echo to the team. Both deliver access, not the content itself – and the seal is gone once it has been collected. Intercept one today and open it in twenty years, and you find a way into a conversation that expired and was deleted long ago.
What tunnl. cannot prevent
- Whoever has the whole link can read. Only share it with the right person. For sensitive content: set a password and share it via a different channel.
- An insecure device stays insecure. Malware or someone looking over your shoulder sees the message after decryption.
- Once read is once seen. We cannot prevent screenshots or copies.
- If we send the e-mail for you, we see the link. With branded sending (the “gotthrd” option) our server assembles the e-mail – the link with the key passes through it at that moment. We do not store it. If you set a password, the link alone is useless to anyone, including us. If you send the link yourself, it never passes us at all.
- Trust in the delivered site. As with any service in the browser, the code tunnl.ch delivers is what runs. We load nothing from third parties and protect the site with HTTPS and strict security rules.
Write a confidential message Read on: What tunnl. is for · Help · Privacy