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: 21 oktober 2026
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 op jouw apparaat en één dat alleen je herstelzin kan openen. Je hebt altijd twee van de drie stukken nodig om de deur te openen.
Drie delen, elke twee openen de deur. Wij hebben er één. Je apparaat heeft er één. Je herstelzin opent de derde.
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
Geen Amerikaanse cloudhosting, dus geen blootstelling aan de CLOUD Act. We hosten bij Scaleway. De enige externe aanroep is de malwarecheck: de hash van een bestand, nooit de inhoud (zie wat we wel en niet zien, hieronder).
Dit zijn geen regels die we zomaar kunnen aanpassen; het zijn fundamentele ontwerpkeuzes.
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
Elke groepssleutelset wordt bij aanmaak en rotatie met beide handtekeningen ondertekend, en elke auditregel draagt ze allebei. Die handtekeningen in de client bij elk laden controleren, zodat een door de server verwisselde sleutel wordt geweigerd, is nog openstaand werk: zie openstaand werk. Tot die tijd worden de handtekeningen opgeslagen, niet afgedwongen.
Hashing & content-addressing
BLAKE3 + SHA-256
content addressing · keyed nonces · FIPS 180-4
BLAKE3 over elk versleuteld blok geeft het blok zijn adres, zodat identieke ciphertext één keer wordt opgeslagen. Blok-nonces komen uit een keyed BLAKE3 over de bestandssleutel, dus dezelfde inhoud in twee bestanden versleutelt anders en is nooit over bestanden heen te matchen. Je client geeft daarnaast een SHA-256 van de platte inhoud op voor de malwarecheck (zie wat we zien).
Sleutelbewaring
Pedersen VSS
Ristretto255 · 2-of-3 threshold · verifiable shares
Splitst jouw hoofdsleutel in drie delen: server, apparaat, herstelzin. Elke twee herstellen de sleutel, geen enkel deel alleen, en elk deel is te verifiëren tegen een commitment. Zie sleutelbewaring.
Sleutelafleiding
HKDF-SHA512 + Argon2id
RFC 5869 + RFC 9106
HKDF-SHA512 leidt werksleutels af uit je hoofdsleutel via domein-gescheiden info-strings. Argon2id (64 MiB geheugen, 3 iteraties) rekt je pincode op voordat die het apparaatdeel ontgrendelt, en de wachtwoordzin die een gast intypt voordat die een transfer opent. Bewust traag, zodat raden onbetaalbaar is.
Willekeur
OsRng / getrandom
OS-CSPRNG · Web Crypto API in browser
Alle willekeurige data komt van de OS-CSPRNG via getrandom, in de browser via de Web Crypto API, achter één enkel toegangspunt. Geen eigen algoritmes, geen 'we lezen wat tijdbits uit een variabele'.
Nieuw apparaat koppelen
SPAKE2 + hybrid ECIES
RFC 9382 · X25519 + ML-KEM-768
Een nieuw apparaat krijgt zijn deel van een apparaat dat je al hebt. SPAKE2 over een korte eenmalige code voorkomt dat de server, die alleen doorgeeft, zich voor een van beide kanten uitgeeft: een gemanipuleerd bericht levert precies één gok naar de code op. Daarbinnen houdt hybride ECIES het transcript vertrouwelijk, ook voor een toekomstige quantumlezer die de code kent.
Geen custom crypto. Alles peer-reviewed, gestandaardiseerd, en publiekelijk te verifiëren.
Hier maken we onze zero-knowledge-belofte technisch waar. Niet op basis van beleid, maar op basis van wiskunde.
Bij registratie maakt je browser een willekeurig geheim en splitst dat in drie delen. Elke twee bouwen het weer op; één deel alleen zegt niets over het geheim, en elk deel is te controleren op manipulatie.
Server-deel
Op onze server, vrijgegeven aan jou nadat je bent ingelogd.
Apparaat-deel
In je browser of telefoon, ontgrendeld met je pincode of een passkey die het apparaat nooit verlaat.
Herstel-deel
Alleen je herstelzin van 24 woorden kan dit deel openen. Hiermee kom je weer binnen als je een apparaat kwijtraakt.
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.
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
Wie je bent en wanneer je inlogt
E-mail en naam voor login en MFA; inlogtijdstippen en IP-adressen voor beveiliging en audit.
Met wie je werkt
In welke groepen je zit en sinds wanneer, en wie wat naar wie stuurt: afzender, ontvanger, vervaldatum, status en de titel, tenzij de afzender die ook versleutelt.
Hoeveel je opslaat
Aantallen bestanden en versleutelde omvang per blok van 4 MB voor quota, en de vorm van je mappenboom: welke map in welke zit en hoeveel bestanden erin staan, nooit hoe iets heet.
Vingerafdrukken, geen inhoud
BLAKE3-hashes van versleutelde blokken voor adressering en deduplicatie, en de SHA-256 die je client per upload opgeeft voor een malwarecheck bij OPSWAT MetaDefender. Die laatste zegt of een bestand een bekend publiek bestand is en niets over een uniek bestand.
Auditgebeurtenissen
Welke actie, op welk resource-ID, wanneer, ondertekend op jouw apparaat.
Zoekopdrachten over leesbare titels
Wat je intypt in het zoekvak van je transfer- en aanvraaglijsten draait op de server over de titels. In bestands- en chatinhoud wordt op de server nooit gezocht.
Wat we níét zien
De inhoud van je bestanden
Versleutelde blokken, nooit platte tekst.
Bestandsnamen, -typen en exacte groottes
Versleuteld met de bestandssleutel en aan het bestand gebonden, zodat ze niet te verwisselen zijn.
Mapnamen
Versleuteld met de sleutel van de map. De server ziet de boom, niet hoe iets heet.
Chatberichten
Elk bericht wordt op je apparaat versleuteld voordat het wordt verzonden. De server is een blinde koerier.
Secure Mail-gesprekken
Berichten en bijlagen versleuteld op je apparaat, ook met gasten buiten Databeamer.
Journaalregels en gedeelde documenten
Geschreven en bewerkt op je apparaat onder de sleutel van het bestand. De server slaat bewerkingen op die hij niet kan lezen.
Antwoorden op aanvraagformulieren
Veldwaarden en geüploade bestanden worden in de browser versleuteld voordat ze ons bereiken.
Berichten bij transfers en aanvragen
Het bericht dat met een transfer of aanvraag meegaat, versleuteld voordat het wordt verzonden.
Tags, labels en beschrijvingen
Alle inhoudelijke metadata zit in versleutelde blobs die aan hun bestand of map gebonden zijn.
Je sleutels
De hoofdsleutel is in drieën gesplitst. Wij hebben één deel, nooit de twee die nodig zijn.
Wachtwoorden, pincodes, herstelzinnen en gastwachtwoordzinnen
Inloggen is een apart systeem. De pincode en herstelzin verlaten je apparaat nooit. Van een gastwachtwoordzin bewaren we alleen de salt.
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. In onze eigen code staat unsafe op compilerniveau uit, in plaats van dat we het alleen ontmoedigen. De bibliotheken eronder bevatten er wel wat, zoals elke cryptografie- of WebAssembly-stack; die set houden we klein, vastgepind en gecontroleerd.
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.
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.
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 organisaties om uiterlijk eind 2026 met de overstap naar post-quantum cryptografie te beginnen en die voor systemen met een hoog risico in 2030 af te ronden. Wij lopen hierop vooruit: onze hybride stack (zie de stack) is al sinds begin 2026 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.
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.
Laatst herzien: 21 oktober 2026