Everyone encrypts. WeTransfer encrypts. Dropbox encrypts. Your email encrypts. And yet, when you press on who holds the key, where the plaintext lives, and who can read along under a court order, it usually gets quiet.
This page sets out plainly what we encrypt, with which algorithms, who can read it, and why that still holds in ten years. A little more technical than the rest of the site. No fog.
Last reviewed: October 21, 2026
The rest of this page walks through what we do, in what order, and with which ingredients. The ideas underneath fit on four cards.
You address a sealed envelope. The courier carries it across. On the way, the envelope doesn't open, not even by the courier. We're the courier. As far as we're concerned, your file is an inscrutable smear of bytes.
Encrypted in your browser. Decrypted in the recipient's browser. Our servers only ever store ciphertext.
Picture a vault building. We built it, we keep the walls standing. But the key to your locker? We never had it. No spare, no master copy, no 'we can request one at reception'. Not because we're virtuous, because, technically, we never receive it.
We can never decrypt your data. Not under duress. Not under a court order. We don't have the key, there's nothing to hand over.
The lock that's safe today might be a wet paper bag in ten years. Quantum computers are coming, slowly but surely, and whatever they'll crack tomorrow, attackers can already record today and decrypt 'later'. So we use locks that hold now and later. Two per door, just to be sure.
Hybrid X25519 + ML-KEM-768 for key exchange. Hybrid Ed25519 + ML-DSA-65 for signatures. Classical and post-quantum, side by side.
One key you can lose is a disaster. One key you can hand over is also a disaster. So we split it three ways: a share on our server, a share on your device, a share that only your recovery phrase can open. Any two of them open the door. We alone can't open anything. You lose one of the three and you're still in.
Three shares, any two open the door. We hold one. Your device holds one. Your recovery phrase opens the third.
Some products mostly explain what they do. Here, first, what we explicitly don't do, and, more importantly, can't.
NO backdoor
no hidden side door for 'staff with access', and none for law enforcement either
NO master key
no key that opens every locker, it doesn't exist, and can't
NO data-recovery email
we can reset your password, not your encrypted data. Lose two of your three shares and the data is gone for everyone, including us.
NO plaintext logs
the server never logs what's inside your files, it can't even read them
NO AI-scanning on your data
not by us, not by third parties, ever
NO US data paths
no US cloud hosting, so no CLOUD Act exposure. The one outside call is the malware check: a file's hash, never its contents (see what we can and can't see, below)
These aren't policies we can flip. These are design choices. We didn't 'lose' the master key, we never made one.
For anyone who wants to verify we're not bluffing: this is what's under the hood. With the real names, RFCs, and standards you can still google.
Symmetric encryption
ChaCha20-Poly1305
RFC 8439 · AEAD
Encrypts every block of your file. Fast in the browser, constant-time (no timing leaks), and with domain-separated AAD per context, ciphertext from context A never accidentally fits context B.
Key exchange
X25519 + ML-KEM-768
RFC 7748 + NIST FIPS 203 · hybrid
For each new recipient, we encrypt the file key with this hybrid combination. Classical (X25519) plus post-quantum (ML-KEM-768), combined via HKDF-SHA512. An attacker has to break both to read anything.
Signatures
Ed25519 + ML-DSA-65
RFC 8032 + NIST FIPS 204 · hybrid
Every group key set is signed with both signatures when it is created or rotated, and every audit entry carries both. Checking those signatures in the client on every load, so that a key the server swapped in is refused, is still open work: see open work. Until then the signatures are stored, not enforced.
Hashing & content addressing
BLAKE3 + SHA-256
content addressing · keyed nonces · FIPS 180-4
BLAKE3 over each encrypted block gives the block its address, so identical ciphertext is stored once. Block nonces come from a keyed BLAKE3 over the file key, so the same content in two files encrypts differently and nothing can be matched across files. Your client also reports a SHA-256 of the plaintext for the malware check (see what we see).
Key custody
Pedersen VSS
Ristretto255 · 2-of-3 threshold · verifiable shares
Splits your master key into three shares: server, device, recovery phrase. Any two reconstruct it, none alone, and every share can be verified against a commitment. See key custody.
Key derivation
HKDF-SHA512 + Argon2id
RFC 5869 + RFC 9106
HKDF-SHA512 derives working keys from your master key with domain-separated info strings. Argon2id (64 MiB memory, 3 iterations) stretches your PIN before it unlocks the device share, and the passphrase a guest types before it unlocks a transfer. Deliberately slow, so guessing is unaffordable.
Randomness
OsRng / getrandom
OS-CSPRNG · Web Crypto API in browser
All randomness comes from the OS CSPRNG via getrandom, in the browser via the Web Crypto API, behind a single entry point. No homemade RNG, no 'we read some time bits from a variable'.
Device approval
SPAKE2 + hybrid ECIES
RFC 9382 · X25519 + ML-KEM-768
A new device gets its share from a device you already have. SPAKE2 over a short one-time code stops the server, which only relays, from standing in for either side: a tampered message buys exactly one guess at the code. Inside it, hybrid ECIES keeps the transcript confidential even from a future quantum reader who learns the code.
No custom crypto. Everything peer-reviewed, standardized, and publicly verifiable.
This is where the zero-knowledge promise is technically backed up. Not as policy. As mathematics.
At registration your browser makes a random secret and splits it into three shares. Any two rebuild it; one on its own says nothing about the secret, and each share can be checked for tampering.
Server share
On our server, released to you after you sign in.
Device share
In your browser or phone, unlocked by your PIN or a passkey that never leaves the device.
Recovery share
Only your 24-word recovery phrase can open it. It gets you back in when you have lost all your devices.
The master key is never stored. It's reconstructed, used to derive identity keys, and immediately wiped from memory.
A claim of 'zero-knowledge' has to be specific. Below: literally what stays visible on our servers, and what doesn't. No hand-waving.
What we do see
Who you are and when you sign in
email address and name for sign-in and two-factor verification; sign-in timestamps and IP addresses for security and audit
Who you work with
which groups you are in and since when, and who sends what to whom: sender, recipient, expiry, status, and the title unless the sender encrypts that too
How much you store
file counts and encrypted sizes per 4 MB block for quotas, and the shape of your folder tree: which folder sits in which and how many files each holds, never what anything is called
Fingerprints, not contents
BLAKE3 hashes of encrypted blocks for addressing and deduplication, and the SHA-256 your client reports per upload for the malware check at OPSWAT MetaDefender; the latter tells whether a file is a known public file and nothing about a unique one
Audit entries
which action, on which object, when, signed on your device
Searches over readable titles
what you type in the search box of your transfer and request lists runs on the server over the titles; file and chat contents are never searched on the server
What we don't see
The contents of your files
ciphertext blocks; plaintext never
File names, types and exact sizes
encrypted with the file key, bound to the file so they cannot be swapped
Folder names
encrypted with the folder's key; the server sees the tree, not what anything is called
Chat messages
every message encrypted on your device before it is sent; the server is a blind courier
Secure Mail conversations
messages and attachments encrypted on your device, including with guests outside Databeamer
Journal entries
written and edited on your device under the file's key; the server stores operations it cannot read
Answers to requests
field values and uploaded files encrypted in the browser before they reach us
Messages with transfers and requests
the message that travels with a transfer or request, encrypted before it is sent
Tags, labels and descriptions
all content-bearing metadata sits inside encrypted blobs bound to their file or folder
Your keys
the master key is split in three; we hold one share, never the two it takes
Passwords, PINs, recovery phrases and guest passphrases
signing in is a separate system; the PIN and recovery phrase never leave your device; for a guest passphrase we keep only the salt
Cryptography is mathematics. But the software running that mathematics has to be built just as carefully, otherwise the chance of error sneaks back in via a buffer overflow or a race condition. The choices below are aimed squarely at that.
Why Rust
The server, the cryptography libraries, and the browser version of those libraries are all written in Rust. Not because it's hip, but because Rust makes an entire class of bugs impossible: buffer overflows, use-after-free, data races. Exactly the categories the overwhelming majority of high-impact security CVEs start in.
The type system enforces design choices. If a key has to be in a particular state, then the wrong state is literally unrepresentable, not 'unlikely', not 'documented', but impossible. In our own code, unsafe is switched off at the compiler level rather than discouraged by policy. The libraries underneath do contain some, as any cryptography or WebAssembly stack does; we keep that set small, pinned and audited.
And: the same Rust code runs in the server and in your browser, via WebAssembly. One source of truth for all cryptography. No 'browser encryption vs. server encryption' divergence that might quietly drift apart under pressure.
Code is, in the end, the residue of thought. How we think determines how the code behaves, under pressure, after three years, in the hands of someone who wasn't there when it was written.
Precision
For us, engineering is a way of thinking. A way of talking about correctness where you don't hope something works, you show that it works. The wrong state of a key, then, shouldn't be 'caught by a PR review'; it should be unrepresentable in the type system itself.
Our background is in functional and type-driven languages, Haskell, Agda, Lean. Languages where you learn to use your type system as a proof assistant rather than a syntax checker. We bring that intuition to Rust, to TypeScript, to every line we write.
Maintainability
But correctness in a single moment isn't enough. Code that's right today and unreadable in two years is still broken. Maintainability isn't a separate quadrant, it's the long-term form of correctness. We write code that's still readable in a few years, by someone who wasn't there when it was written. That principle carries through to how we use our tools.
AI
AI fits into that story, used well. A fine tool to think with, tinker with, iterate ideas with. A good sparring partner when you know what you're asking and what you're getting back.
But we don't want our codebase sliding into slop. So we put it under firm guard rails: it works inside our type systems, our language choices, our principles. It proposes; we decide. An extension, not a replacement.
The server itself, the block storage, the database, the cache, all of it runs on infrastructure inside the European Union. Operated by Full Join B.V., based in Eindhoven. Subject to Dutch law and the GDPR.
We deliberately don't run on US hyperscalers. Not for dogmatic reasons, but because the US CLOUD Act compels US-owned companies to hand over data to US authorities, regardless of where the servers physically sit. We don't fall under it.
Our cryptographic choices follow NIST standards and EU preferences. ENISA and the European PQC roadmap recommend that organisations start their transition to post-quantum cryptography by the end of 2026 and complete it for high-risk systems by 2030. We already have: our hybrid choice (see the stack) has been in place since early 2026.
Should the global standard shift further, we shift with it. Our stack is deliberately crypto-agile: primitives sit behind trait boundaries, so a new one can slot in without dragging half the codebase along.
For the full list of standards Databeamer aligns with, NTA 7516, NEN 7510, ISO 27001, and others, see the compliance page.
No security story is ever finished. This section tracks what we're actively working on, what's planned, and where we know we have ground to cover.
Last reviewed: October 21, 2026