§ 01 · Intro
The receipts. Not the marketing line.
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: April 29, 2026
§ 02 · Principles
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 in your browser, a share in your recovery phrase. Any two of them open the door. We alone can't open anything. You lose one of the three and you're still in.
Shamir's Secret Sharing. Three shares, threshold 2. No single party can reconstruct your master key, not us, not you without a second share.
§ 03 · What we don't have
Some products mostly explain what they do. Here, first, what we explicitly don't do, and, more importantly, can't.
GEEN backdoor
no hidden side door for 'staff with access', and none for law enforcement either
GEEN master key
no key that opens every locker, it doesn't exist, and can't
GEEN data-recovery email
we can reset a login, not encrypted data. Lose two of your three shares and the data is gone for everyone, including us.
GEEN plaintext logs
the server never logs what's inside your files, it can't even read them
GEEN AI-scanning on your data
not by us, not by third parties, ever
GEEN US data paths
no routing through US providers, no CLOUD Act exposure
These aren't policies we can flip. These are design choices. We didn't 'lose' the master key, we never made one.
§ 04 · The stack
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 · hybride
For each new recipient, we wrap 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 · hybride
Key material is always signed with both signatures. Both must verify, otherwise the client refuses the key, even if the server tries to swap one in.
Hashing & content addressing
BLAKE3
cryptografische hash · keyed mode
Fast cryptographic hash for content addressing. In keyed mode for within-file deduplication, so blocks can be reused without the hash leaking content.
Key custody
Shamir's Secret Sharing
2-of-3 threshold
Splits your master key into three shares (server, device, recovery phrase). Any two reconstruct it. None alone. See §5 for the full walkthrough.
Key derivation
HKDF-SHA512 + Argon2id
RFC 5869 + RFC 9106
HKDF-SHA512 derives working keys from your master key with domain-separated info strings. Argon2id (65536 KB memory, 3 iterations) hardens password-derived shares, deliberately slow, to make brute-force attempts 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. No homemade RNG, no 'we read some time bits from a variable'. Domain-separated seeds for each purpose.
No custom crypto. Everything peer-reviewed, standardized, and publicly verifiable.
§ 05 · Key custody
This is where the zero-knowledge promise is technically backed up. Not as policy. As mathematics.
At registration, a random scalar (~253 bits of entropy) is generated and immediately split with Shamir's Secret Sharing into three pieces, threshold 2. The three shares each go to an independent trust domain.
Server share
Lives on our server. Protected by your login (SSO + MFA). Available on every login, only after you've authenticated.
Device share
Lives in your device's keychain. Protected by biometrics or OS credentials. Enables offline unlock and fast login.
Recovery share
With you, as a BIP39 mnemonic, or derived from a password. For account recovery if you lose your device or we're unreachable.
The master key is never stored. It's reconstructed, used to derive identity keys, and immediately wiped from memory.
§ 06 · What we (don't) see
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
Your identity
email and name, used for login and MFA
When you log in
timestamp + IP address, for security and audit
Which workspaces you're in
who collaborates with whom, who's in which workspace, and when they joined
How many files you have
counts per workspace and per user, for quota management
How large they are
in encrypted bytes, approximately equal to the plaintext
Hashes of encrypted blocks
BLAKE3 over ciphertext, for addressing and dedup, never over the contents
Who sends to whom
sender, recipient, title, expiration, status, required for routing and recognizable notifications (without a title you can't tell what's waiting for you)
Audit events
which action, on which resource ID, when, signed client-side
What we don't see
The contents of your files
ciphertext blocks; plaintext never
File names and folder structure
directory indexes are encrypted; we see no names, paths, or hierarchy
Chat messages
every message encrypted in the browser before it's sent, server is a blind courier
Request form responses
field values are encrypted in the browser before they reach us
Messages on transfers and requests
the accompanying note or context attached to a transfer or request, encrypted in the browser before it's sent
Tags, labels, descriptions
all content-bearing metadata sits inside the encrypted indexes
Your master key and derived keys
split into three shares; we hold at most one, never the required two
What you search for
search runs locally over a decrypted index in your browser
Passwords and recovery phrases
auth is handled separately in a dedicated login system; recovery phrases never leave your device
§ 07 · The build
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. unsafe appears nowhere in our code; that's a hard rule, not an aspiration.
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.
§ 08 · The practice
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.
§ 09 · EU sovereignty
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 all digital products move to post-quantum cryptography in 2026. We already do, our hybrid choice (see §4) has been in place since 2025.
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.
§ 10 · Open work
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.
Research into homomorphic encryption: computing on encrypted data without decryption. This would enable server-side operations like search and filtering while preserving Databeamer's zero-knowledge guarantee.
We are preparing for the formal ISO 27001:2022 audit. Our ISMS is tuned to the standards.
§ 11 · Further reading
Last reviewed: April 29, 2026