§ 01 · Inleiding
De receipts. Niet het marketing-praatje.
Privacy is meer dan een marketingterm. Natuurlijk versleutelen wij je data, net als veel andere leveranciers. Het verschil zit in de details: wie heeft de sleutels en wie kijkt er mee bij een rechterlijk bevel? Wij zijn daar graag duidelijk over.
Op deze pagina duiken we in de techniek. We laten je zien welke algoritmes we gebruiken en hoe we jouw data ook voor de toekomst veilig houden. Iets technischer dan op de rest van deze site, maar wel volkomen transparant.
Laatst herzien: 29 april 2026
§ 02 · Principes
Op de rest van deze pagina leggen we precies uit wat we doen en welke techniek we daarvoor gebruiken. Maar het onderliggend concept laat zich samenvatten in vier heldere principes.
Zie het als een verzegelde envelop. Jij schrijft het adres en de koerier brengt de envelop naar de ontvanger. Onderweg kan niemand de envelop openen, ook de koerier niet. Wij zijn die koerier. Voor ons is jouw bestand niets meer dan een onleesbare reeks bytes.
Jouw data wordt versleuteld in je browser en pas ontsleuteld bij de ontvanger. Onze servers zien alleen onleesbare code (ciphertext).
Stel je een kluisgebouw voor. Wij hebben het gebouw neergezet en onderhouden de muren. Maar de sleutel van jouw persoonlijke kluis? Die hebben we nooit gehad. Geen reservesleutel, geen loper en geen kopie bij de receptie. Niet omdat we zo braaf zijn, maar omdat we de sleutel technisch gezien nooit kunnen ontvangen.
Wij kunnen jouw data nooit ontsleutelen. Zelfs niet als we onder druk worden gezet of een gerechtelijk bevel krijgen. We hebben simpelweg de sleutel niet.
Een slot dat vandaag veilig is, kan over tien jaar waardeloos zijn. Quantumcomputers zijn in opkomst. Wat zij straks kunnen kraken, kunnen aanvallers nu al onderscheppen om 'later' te lezen. Daarom kiezen we voor sloten die nu én in de toekomst standhouden. Twee verschillende sloten per deur, voor de zekerheid.
Een hybride combinatie van klassieke en post-quantum algoritmes (X25519 + ML-KEM-768 voor sleutels en Ed25519 + ML-DSA-65 voor handtekeningen).
Één sleutel die je kunt kwijtraken is een risico. Één centrale sleutel die iemand kan stelen is ook een ramp. Daarom splitsen we de toegang in drie stukken: één op onze server, één in jouw browser en één in je herstelfrase. Je hebt altijd twee van de drie stukken nodig om de deur te openen.
Shamir's Secret Sharing. Wij kunnen nooit alleen bij je data. Verlies jij één onderdeel? Dan heb je via de andere twee nog steeds toegang. Geen enkele partij kan zelfstandig de hoofdsleutel reconstrueren.
§ 03 · Wat we niet hebben
Naast wat we wel kunnen, vertellen we graag ook eerst wat we expliciet niet doen. En belangrijker nog: wat we technisch simpelweg niet kúnnen.
GEEN backdoor
Er is geen verborgen achterdeur voor medewerkers of opsporingsdiensten.
GEEN masterkey
Er bestaat geen loper die alle kluisjes opent. Die sleutel is er niet en kan technisch ook niet bestaan.
GEEN 'data recovery mail'
Je inloggegevens kunnen we resetten, maar je versleutelde data niet. Verlies je twee van je drie sleutels (shares)? Dan is je data voor iedereen weg, ook voor ons.
GEEN logs in platte tekst
Onze servers loggen nooit de leesbare inhoud van je bestanden.
GEEN AI-scans op jouw data
Niet door ons, niet door derden. Nooit.
GEEN Amerikaanse inmenging
Jouw data loopt nooit via Amerikaanse providers en/of platformen. We hosten bij Scaleway. Zo voorkomen we elke blootstelling aan de Amerikaanse wetgeving. Geen inzage via CLOUD Act en nagenoeg geen kans op een shut-down vordering.
Dit zijn geen regels die we zomaar kunnen aanpassen; het zijn fundamentele ontwerpkeuzes.
§ 04 · De stack
Voor wie wil verifiëren dat we niet bluffen: dit is wat er onder de motorkap zit. Inclusief de officiële namen, RFC's en standaarden die je zelf kunt controleren.
Symmetrische versleuteling
ChaCha20-Poly1305
RFC 8439 · AEAD
Versleutelt elk blok van je bestand. Snel in de browser en constant-time (beveiligd tegen timing-aanvallen). Door domein-gescheiden AAD per context kan ciphertext uit 'context A' nooit per ongeluk in 'context B' worden gebruikt.
Sleuteluitwisseling
X25519 + ML-KEM-768
RFC 7748 + NIST FIPS 203 · hybride
Voor elke nieuwe ontvanger versleutelen we de bestandssleutel met deze hybride combinatie. We combineren klassiek (X25519) met post-quantum (ML-KEM-768) via HKDF-SHA512. Een aanvaller zou beide algoritmes moeten breken om toegang te krijgen.
Digitale handtekeningen
Ed25519 + ML-DSA-65
RFC 8032 + NIST FIPS 204 · hybride
Al het sleutelmateriaal wordt dubbel ondertekend. Beide handtekeningen moeten kloppen, anders weigert de client de sleutel direct, zelfs als de server een vervangende sleutel zou aanbieden.
Hashing & content-addressing
BLAKE3
cryptografische hash · keyed mode
Een razendsnelle hash voor content-addressing. We gebruiken de keyed-modus voor deduplicatie binnen bestanden, zodat blokken hergebruikt kunnen worden zonder dat de hash de werkelijke inhoud lekt.
Sleutelbewaring
Shamir's Secret Sharing
2-of-3 threshold
Splitst jouw hoofdsleutel in drie delen (shares): server, apparaat en herstelfrase. Elke combinatie van twee delen kan de sleutel herstellen; één deel alleen is waardeloos. Zie §5 voor de volledige technische onderbouwing.
Sleutelafleiding
HKDF-SHA512 + Argon2id
RFC 5869 + RFC 9106
HKDF-SHA512 leidt werksleutels af uit je hoofdsleutel via domein-gescheiden info-strings. Argon2id (64MB geheugen, 3 iteraties) beveiligt de wachtwoord-afgeleide delen. Dit proces is bewust traag gemaakt om brute-force-aanvallen onmogelijk te maken.
Willekeur
OsRng / getrandom
OS-CSPRNG · Web Crypto API in browser
Alle willekeurige data is afkomstig van de OS-CSPRNG via getrandom, of in de browser via de Web Crypto API. We gebruiken geen eigen algoritmes of onbetrouwbare variabelen; we werken uitsluitend met domein-gescheiden seeds voor elk specifiek doel.
Geen custom crypto. Alles peer-reviewed, gestandaardiseerd, en publiekelijk te verifiëren.
§ 05 · Sleutelbewaring
Hier maken we onze zero-knowledge-belofte technisch waar. Niet op basis van beleid, maar op basis van wiskunde.
Bij registratie genereren we een willekeurige waarde (random scalar met ~253 bits entropie). Deze wordt direct via Shamir's Secret Sharing gesplitst in drie delen, met een drempelwaarde van twee. Elk deel wordt opgeslagen in een onafhankelijk domein:
Server-deel
Staat op onze server en is beveiligd via jouw login (SSO + MFA). Het wordt pas vrijgegeven nadat je succesvol bent geauthenticeerd.
Apparaat-deel
Staat in de keychain van je eigen apparaat en is beveiligd via biometrie of je systeemwachtwoord. Dit maakt snel inloggen en offline ontgrendelen mogelijk.
Herstel-deel
Dit deel heb jij in eigen beheer, bijvoorbeeld als BIP39-mnemonic (woordreeks) of afgeleid van een sterk wachtwoord. Dit is je achterwacht voor als je een apparaat kwijtraakt of als onze server onbereikbaar is.
De hoofdsleutel (masterkey) zelf wordt nooit opgeslagen. Deze wordt alleen tijdelijk opgebouwd om je identiteitssleutels af te leiden en daarna direct uit het geheugen gewist.
§ 06 · Wat we (niet) zien
Een claim van 'zero-knowledge' moet specifiek zijn. Hieronder staat precies wat er op onze servers zichtbaar is en wat niet. Geen vaagheden, maar volledige transparantie.
Wat we wél zien
Je identiteit
E-mailadres en naam (nodig voor inlog en MFA).
Activiteit
Tijdstip van inloggen en je IP-adres (voor beveiliging en audits).
Workspace-structuur
Wie er met wie samenwerkt, wie lid is van welke Workspace en wanneer zij zijn toegevoegd.
Opslaggegevens
Het aantal bestanden per Workspace en per gebruiker (voor quotabeheer).
Bestandsgrootte
De omvang in versleutelde bytes (vrijwel gelijk aan de originele grootte).
Hashes van versleutelde blokken
BLAKE3-hashes van de ciphertext (nodig voor adressering en deduplicatie, zonder de inhoud te onthullen).
Verzendinformatie
Afzender, ontvanger, titel, vervaldatum en status. Dit is nodig voor de routing en herkenbare meldingen.
Audit-events
Welke actie is uitgevoerd op welk resource-ID en wanneer; altijd digitaal ondertekend door de client.
Wat we níét zien
De inhoud van je bestanden
Wij zien alleen ciphertext-blokken; de originele data bereikt onze server nooit.
Bestandsnamen en mappenstructuur
Directory-indexen zijn volledig versleuteld. Wij zien geen namen, paden of hiërarchie.
Chatberichten
Elk bericht wordt in de browser versleuteld vóór verzending. De server fungeert als een blinde koerier.
Ingevulde formulieren
Veldwaarden worden lokaal in de browser versleuteld voordat ze naar ons worden verzonden.
Berichten bij transfers
De begeleidende tekst of toelichting bij een transfer is voor ons onleesbaar.
Tags, labels en omschrijvingen
Alle inhoudelijke metadata wordt opgeslagen in de versleutelde indexen.
Je masterkey en afgeleide sleutels
De sleutel is gesplitst in drie delen. Wij beheren er maximaal één; we hebben er technisch altijd twee nodig.
Je zoekopdrachten
Zoeken gebeurt lokaal in jouw browser op een ontsleutelde index.
Wachtwoorden en herstelfrases
Authenticatie verloopt via een gescheiden systeem. Jouw herstelfrase verlaat je apparaat nooit.
§ 07 · De bouw
Cryptografie is wiskunde. Maar de software die die wiskunde uitvoert, moet met dezelfde precisie zijn gebouwd. Anders glippen beveiligingsrisico's alsnog naar binnen via een buffer overflow of race condition. Onze technische keuzes zijn er volledig op gericht om dit te voorkomen.
Waarom Rust?
De server, de cryptografie-bibliotheken en de browser-versie zijn allemaal geschreven in Rust. Niet omdat het een trend is, maar omdat Rust een hele categorie programmeerfouten simpelweg onmogelijk maakt. Denk aan buffer overflows, use-after-free en data races; precies de kwetsbaarheden die de basis vormen voor het overgrote deel van alle grote beveiligingslekken (CVE's).
Het type-system van Rust dwingt veilige ontwerpkeuzes af. Als een sleutel zich in een specifieke staat moet bevinden, dan is een afwijkende staat technisch niet representeerbaar. Het is niet 'onwaarschijnlijk' of 'afgeraden', maar simpelweg onmogelijk. Bovendien is het gebruik van unsafe code bij ons verboden: dat is een harde architectuurregel, geen vrijblijvende wens.
Dezelfde Rust-code draait zowel op onze servers als in jouw browser (via WebAssembly). Dit betekent dat er één bron van waarheid is voor alle cryptografie. Er is geen verschil tussen hoe de browser en de server versleutelen; de logica is identiek en wijkt nooit af.
§ 08 · De praktijk
Code is de optelsom van hoe je denkt. Onze denkwijze bepaalt hoe de software zich gedraagt: onder druk, over drie jaar, of in de handen van een nieuwe ontwikkelaar.
Precisie
Engineering is voor ons een discipline van bewijsvoering. Je moet niet hopen dat iets klopt; je moet laten zien dat het klopt. Een verkeerde status van een cryptografische sleutel moet niet afhankelijk zijn van een oplettende collega tijdens een handmatige controle (code review); die fout moet technisch onmogelijk zijn door de inrichting van het systeem zelf.
Onze achtergrond ligt in functionele en type-gestuurde talen zoals Haskell, Agda en Lean. Talen waarin je leert om het typesysteem te gebruiken als bewijsassistent in plaats van alleen als spellingcontrole. Die intuïtie nemen we mee naar elke regel code die we schrijven in Rust of TypeScript.
Onderhoudbaarheid
Correctheid op één specifiek moment is niet genoeg. Code die nu werkt, maar over twee jaar onbegrijpelijk is, is in feite stuk. Onderhoudbaarheid is simpelweg de langetermijnvorm van correctheid. We schrijven code die over jaren nog leesbaar is, ook voor wie er niet bij was toen het geschreven werd. Dat principe bepaalt hoe we ons gereedschap selecteren en gebruiken.
De rol van AI
AI past in dit verhaal, mits je het juist inzet. Het is een uitstekend hulpmiddel om mee te sparren, te experimenteren of ideeën uit te werken. Een sterke partner, zolang je precies weet wat je vraagt en wat je terugkrijgt.
We waken er echter voor dat onze codebase vervuilt met slordige, gegenereerde code. Daarom stellen we harde kaders: AI werkt binnen onze typesystemen, onze taalkeuzes en onze principes. Het doet voorstellen; wij beslissen. Het is een verlengstuk van onze expertise, geen vervanging ervan.
§ 09 · EU-soevereiniteit
De server, de opslag, de database en de cache: onze volledige infrastructuur bevindt zich binnen de Europese Unie. Het beheer is in handen van ons bedrijf Full Join B.V., gevestigd in Eindhoven. Daarmee vallen we volledig onder het Nederlands recht en de AVG.
We maken bewust geen gebruik van Amerikaanse 'hyperscalers'. Niet uit dogma, maar vanwege de US CLOUD Act en het potentiële risico op een 'kill switch'. De Cloud Act verplicht Amerikaanse bedrijven om data af te staan aan de autoriteiten, ongeacht waar de servers fysiek staan. Amerikaanse instanties hebben ook de macht om organisaties of personen de toegang tot applicaties te ontzeggen of zelfs deze applicaties te doen stoppen. Door de keuze voor een Europese basis, valt jouw data buiten het bereik van deze instanties.
Onze cryptografie volgt de standaarden van NIST en de richtlijnen van de EU. De Europese PQC-roadmap (ENISA) adviseert om uiterlijk in 2026 over te stappen op post-quantum cryptografie. Wij lopen hierop vooruit: onze hybride stack (zie §4) is al sinds 2025 de standaard.
Mochten wereldwijde standaarden veranderen, dan bewegen wij moeiteloos mee. Onze architectuur is bewust 'crypto-agiel' ontworpen. De cryptografische bouwstenen zitten achter strikte interfaces (trait-grenzen) verborgen. Hierdoor kunnen we nieuwe algoritmes implementeren zonder de rest van de codebase overhoop te halen.
Voor de volledige lijst met certificeringen en standaarden (zoals NTA 7516, NEN 7510 en ISO 27001), verwijzen we je graag naar onze compliance-pagina.
§ 10 · Open werk
Geen beveiligingsverhaal is ooit af. In deze sectie staat wat we actief aan werken, wat gepland is, en waar we weten dat er nog terrein te winnen valt.
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 · Verder lezen
Laatst herzien: 29 april 2026