Waarom u ons kunt vertrouwen
Op deze vier dingen rust Paramant. Bij elk ziet u wat het voor u betekent en waar u het zelf nakijkt.
De servers staan bij Hetzner in Neurenberg, Duitsland, onder de AVG. De versleutelde bestanden staan alleen op onze servers in de EU. E-mail gaat nu nog via Resend in de Verenigde Staten, en dat is de enige Amerikaanse partij in de keten; we stappen over naar een Nederlandse aanbieder. Een eenmalige link mailen wij niet; die geeft u zelf door. Een uitnodiging om te ondertekenen bevat de helft van de documentsleutel, en de andere helft geeft de relay alleen aan de ingelogde ontvanger, dus die mail alleen opent het document niet. Bij versturen naar ontvangers op naam ligt het anders: de uitnodiging bevat de link met het token, en de ophaalcode gaat ook per mail. Wie beide mails leest, kan het bestand openen. Daarom zeggen we niet dat geen Amerikaanse partij ooit een sleutel kan raken. De lijst met subverwerkers staat op privacy. Elke partij met haar status: /partners.
Uw browser maakt de ondertekeningssleutel, en die komt nooit op onze server. Maakt u een verzoek in de browser, dan bewaart de server alleen versleutelde gegevens.
Elke handtekening komt in een openbaar logboek waar alleen iets bij kan, niets uit. Een getekend document is te controleren zonder contact met ons.
De server is source-available onder BUSL-1.1. U kunt precies lezen wat hij met uw bestand doet, en hem op uw eigen server draaien.
In een strafzaak bij de rechtbank Rotterdam had een cliënt vertrouwelijke informatie in ChatGPT gezet. Het was de cliënt, niet de advocaat. Op 12 juni 2026 oordeelde de rechter-commissaris dat het invoeren van zulke informatie in een externe AI-dienst als openbaarmaking kan gelden, waardoor de informatie haar vertrouwelijke karakter verliest (ECLI:NL:RBROT:2026:9319, gepubliceerd op 30 juli 2026). Dat is één rechter-commissaris in één zaak, zonder hoger beroep. Het is geen vaste rechtspraak. Het laat wel zien dat een rechter nu vraagt waar een document terechtkomt. Het antwoord van Paramant zit in de bouw, niet in een contract: het bestand wordt in uw browser versleuteld en de server heeft nooit een leesbare kopie. Dit is geen juridisch advies; vraag uw eigen adviseur wat uw zaak nodig heeft.
Wat er is geaudit
Drie externe beveiligingsaudits in april 2026 hebben de code van de server bekeken: twee door R. Zwarts, een door Ryan Williams van Smart Cyber Solutions. Samen leverden ze 40 bevindingen op, waarvan 4 kritiek. Data, aantallen en de commit die elke reeks oploste, staan in de audittabel op de docs-pagina, en elke bevinding staat beschreven in SECURITY.md in de openbare code.
De review van Smart Cyber Solutions staat volledig online, bevinding voor bevinding, als het auditrapport van april 2026. Alleen de ruwe pentest-uitvoer erachter is niet gepubliceerd. Een volgende externe review van versie 3.0.0 is gepland.
Voor uw NEN 7510-dossier
Wat er nu ligt: een NEN 7510-tabel in de DICOM-handleiding en een IEC 62443-tabel in de OT-handleiding, openbaar en gratis op elk plan. Dat is documentatie voor uw eigen dossier, geen certificaat. Mail privacy@paramant.app voor de beheersmaatregelen die u nodig heeft.
Hieronder staat de techniek, voor uw IT-leverancier of auditor.
Rechtsgebied en privacy
Paramant is van een Nederlands bedrijf: Paramantis Solutions B.V. in Harderwijk, KvK 42115132. Een aantal bekendere Nederlandse namen in deze markt valt inmiddels onder een eigenaar in het buitenland; deze niet. De tabel hieronder toont elk punt dat het product raakt, ook de ene Amerikaanse uitzondering. Zo kunt u het zelf nagaan en hoeft u ons niet op ons woord te geloven.
| Locatie van de servers | Hetzner Neurenberg, Duitsland |
| Rechtsgebied | EU / Duitsland (AVG) |
| Amerikaanse CLOUD Act | De versleutelde bestanden staan alleen op onze servers in de EU. E-mail gaat nu nog via Resend in de Verenigde Staten. Bij versturen naar ontvangers op naam bevat die mail de link met het token en, in een tweede mail, de ophaalcode: samen openen ze het bestand. Een uitnodiging om te ondertekenen bevat de helft van de documentsleutel; de andere helft krijgt alleen de ingelogde ontvanger van de relay. Resend, onze e-mailprovider, is de enige Amerikaanse partij in de keten; we stappen over naar een Nederlandse aanbieder. Zie privacy. Actuele status: /partners. |
| Wat bewaard wordt | Geen leesbare inhoud, geen sleutels. Alleen: de hash van de overdracht, het tijdstip van aanmaken, de versleutelde grootte per blok (tot 5 MB; precies 5 MB bij de live overdracht, ongeveer de bestandsgrootte bij een eenmalige link of een verzending naar een persoon) en het aantal keer bekeken. Verwijderd na de laatste keer lezen. |
| IP-logging | De toegangslog van Nginx staat uit in de deploy-configuratie (access_log off op elk serverblok dat de site en de relays bedient in deploy/nginx-paramant-live.conf). De edge (Caddy) die voor nginx staat, schrijft wel een toegangslog met het clientadres, het tijdstip, het pad en de user-agent (zie privacy). Bij een verzending naar ontvangers op naam staat het token in het pad van de ontvangstlink (/ontvang/<token>), dus dat kan in die log terechtkomen. Er wordt geen aparte bewaartermijn beloofd. Bij een relay die u zelf host is het andersom: deploy/nginx-selfhost.conf schrijft een toegangslog met als eerste veld het adres van de client. Zet die uit als u dat niet wilt. |
| Analytics | Geen. Geen scripts van derden op de relay of de API. |
Uitgangspunt
De relay is een tussenpersoon die niet vertrouwd hoeft te worden. Voor overdrachten en voor ondertekenverzoeken die in een browser zijn gemaakt, bewaart hij alleen versleutelde gegevens en heeft hij geen toegang tot sleutels of leesbare inhoud. Ook een volledig overgenomen relay kan daarvan niets lezen, vervalsen of achteraf terughalen. Dat is geen beleid, het is een cryptografische garantie. Die garantie geldt niet voor de gehoste ondertekenprocedure op de /v1-API, niet voor versturen naar ontvangers op naam en niet voor uploads via de extensies. Bij de /v1-API krijgt de relay het document om de procedure uit te voeren. Bij versturen naar ontvangers op naam gaat het token dat de sleutel opent één keer langs de relay, om in de uitnodiging te worden gemaild. En uploads via de extensies voor Chromium en Outlook worden nu nog op de server versleuteld (zie het kader hieronder). Op die drie plekken is de bescherming beleid. Dat zeggen we liever dan de garantie te laten gelden waar ze niet kan gelden.
De garantie hierboven geldt voor overdrachten vanuit de officiële SDK's (sdk-py 3.0.0, sdk-js 3.0.0) en de webapp Versturen. Die versleutelen allemaal in de client, voordat er iets het apparaat verlaat. Twee uitzonderingen. Versturen naar ontvangers op naam (per e-mailadres) is niet zero-knowledge: uw browser pakt de sleutel per ontvanger in onder een token, maar dat token gaat één keer langs de relay om in de uitnodiging te worden gemaild. Op dat moment zou de relay het bestand kunnen openen, en de uitnodiging en de ophaalcode gaan via onze mailprovider. Wilt u dat alleen de ontvanger de sleutel heeft, stuur dan een eenmalige link: daar staat de sleutel alleen achter het #-teken van de link die u zelf doorgeeft. De extensies voor Chromium en Outlook versleutelen nu nog op de server, terwijl hun versleuteling in de client wordt afgemaakt. Tot die overstap klaar is, behandelt u uploads via een extensie als versleuteld op de relay, niet als zero-knowledge. Status per client: crypto-agility § 06.
De volledige cryptografische architectuur staat op de architectuurpagina.
Cryptografie
De post-quantumalgoritmen komen uit de NIST-standaarden (FIPS 203, 204, 205, 206). Daarnaast gebruiken we gevestigde klassieke bouwstenen: ECDH P-256 naast ML-KEM (hybride), AES-256-GCM, HKDF-SHA256 en SHA3-256, en op de relay Argon2id voor wachtwoord-hashing en Ed25519 voor de licentiehandtekening. Niets zelfgemaakt. Geen eigen sleuteluitwisseling. De relay levert 3 KEMs en 17 signature-algoritmen mee. De standaardmodus core laadt ML-KEM-768 en ML-DSA-65; de modus extended laadt ze allemaal. De client kiest, de relay controleert, en het actuele register staat op /v2/capabilities. Zie crypto-agility voor het berichtformaat en de volledige tabel met algoritmen.
| Algoritme | Rol | Standaard |
|---|---|---|
| ML-KEM-768 | Sleutelinkapseling (post-quantum KEM) | NIST FIPS 203 |
| ECDH P-256 | Klassieke sleuteluitwisseling (hybride) | NIST SP 800-56A |
| HKDF-SHA256 | Sleutelafleiding uit gedeelde geheimen | RFC 5869 |
| AES-256-GCM | Symmetrische versleuteling en authenticatie | NIST SP 800-38D |
| ML-DSA-65 | Digitale handtekeningen (identiteit van de relay) | NIST FIPS 204 |
| Argon2id | Wachtwoord op een overdracht (hash, optionele module) | RFC 9106 |
| SHA3-256 | Merkle-hashing van het CT-log | NIST FIPS 202 |
Hybride sleuteluitwisseling
Geauthenticeerde overdrachten vanuit de webapp Versturen gebruiken ML-KEM-768 en ECDH P-256 tegelijk. Het gedeelde geheim is de aaneenschakeling van beide, dus wie er één breekt, wint daar niets mee. Dit beschermt tegen aanvallen waarbij nu wordt opgeslagen om later te ontsleutelen, en blijft werken met klassieke infrastructuur.
Vooraf gedeeld geheim (PSS)
Een optioneel wachtwoord dat verzender en ontvanger buiten Paramant om afspreken. De verzender opent een sessie met als commitment de SHA3-256 van dat wachtwoord. De client van de ontvanger stuurt daarna het wachtwoord zelf naar /v2/session/join. De relay hasht het, vergelijkt het met het commitment en koppelt pas dan de publieke sleutels van de ontvanger aan de sessie; wie het eerst aansluit, krijgt de plek. Wat dat oplevert, is sleutelbinding: een derde die het wachtwoord niet kent, kan geen eigen sleutels registreren als die van de ontvanger.
Wat het niet oplevert, is vertrouwelijkheid tegenover ons. Het wachtwoord gaat niet mee in de sleutelafleiding: hkdf_aes_key in crypto-wasm/src/lib.rs neemt de gedeelde geheimen van ML-KEM en ECDH en verder niets. De ontvanger stuurt het wachtwoord leesbaar naar de relay. Een relay met code die wij niet schreven, leest het dus, en kan zijn eigen sleutels koppelen wat het commitment ook zegt. PSS maakt het een buitenstaander moeilijker om sleutels te injecteren; het is geen verdediging tegen de relay zelf. Het is een functie van de relay-API, en de webapp op deze site gebruikt het niet.
Opbouw van de relay
Versleutelde blobs staan in het procesgeheugen en worden nooit naar schijf geschreven. Een herstart van de relay wist alle blobs. Geen database, geen schrijfacties naar het bestandssysteem.
Elke blob wordt vernietigd na de laatste keer lezen die de link toestaat. De webapp en de extensies verwijderen het bestand op elk plan na de eerste keer lezen. Via de API kan een betaalde link vaker gelezen worden: tot 10 keer op Firm en 100 keer op Enterprise. Het geheugen wordt direct overschreven met nullen. Er is geen tweede kans om het op te halen.
Bij de live overdracht (Samen, nu: versleuteld naar de sleutel van de ontvanger) wordt elk blok opgevuld tot precies 5 MB, zodat DPI er niets uit kan afleiden. Eén zo'n blok verraadt geen bestandsgrootte, type of inhoud. Een eenmalige link en een verzending naar een persoon worden niet opgevuld: daar zien het netwerk en de relay de versleutelde grootte, die ongeveer de bestandsgrootte is. Heeft een overdracht meer dan één blok nodig, dan gaat het aantal blokken onversleuteld mee. Het aantal blokken is dus zichtbaar, en de grootte is tot op een orde van grootte in te schatten (auditbevinding 5, geaccepteerd).
Elke relay maakt bij de eerste start een post-quantum sleutelpaar voor ondertekenen. Registraties worden ondertekend en vastgelegd in de CT-keten, en verified_since bewijst een doorlopende identiteit.
Wat een overgenomen relay niet kan
/v1, het versturen naar ontvangers op naam en de extensies heeft de relay alleen versleutelde gegevens, geen sleutelsInloggen
Paramant heeft geen wachtwoorden. Mensen loggen in met hun e-mailadres en een tijdgebonden code uit een authenticator-app. Machines gebruiken API-sleutels die lang geldig blijven. Wat we niet hebben, kunnen we ook niet lekken.
U logt in op paramant.app of via een browserextensie met uw e-mailadres en de huidige code van 6 cijfers uit uw authenticator-app. Een sessie loopt af na een uur zonder activiteit, en na twaalf uur in elk geval. De TOTP-controle accepteert HMAC met SHA-256 en SHA-1, dus elke gangbare authenticator-app werkt; SHA-1 is de standaard van RFC 6238 en een aantal veelgebruikte apps kent niets anders. Geschikte authenticator-apps staan op /help/authenticator-apps.
Scripts, SDK-aanroepen, SCADA-koppelingen en IoT-apparaten melden zich aan met een API-sleutel in de HTTP-header X-Api-Key. Geen TOTP, geen sessies, geen mens nodig. Geschikt voor automatisering zonder scherm.
Geen wachtwoorden. Geen wachtwoordhashes. Geen beveiligingsvragen. Geen tokens om een wachtwoord te herstellen. Onze database kan geen wachtwoord lekken, want onze database kent het begrip niet.
Na de TOTP-controle krijgt u een sessietoken van 256 bits als cookie met httpOnly, Secure en SameSite=Lax. Lax en niet Strict, zodat een uitgenodigde ondertekenaar die via een link in zijn mailprogramma binnenkomt niet terug naar het inlogscherm wordt gestuurd; een POST vanaf een andere site draagt nog steeds geen cookie. Het token staat in Redis en verloopt na een uur zonder activiteit, en na twaalf uur in elk geval. API-sleutels komen nooit in de browser.
Beperking van pogingen en bescherming tegen hergebruik
Een TOTP-code hoort bij een tijdvak van dertig seconden. Om een klok die iets afwijkt op te vangen, accepteert de server ook de code van het tijdvak ervoor en erna, dus een code blijft tot ongeveer een minuut na het begin van zijn tijdvak bruikbaar. Elke code wordt bij de eerste acceptatie als gebruikt gemarkeerd, met een atomaire sleutel voor eenmalig gebruik in Redis. Is Redis niet bereikbaar, dan wordt het inloggen geweigerd in plaats van doorgelaten, zodat een code nooit wordt geaccepteerd zonder markering. Inlogpogingen zijn beperkt tot vijf per IP-adres per kwartier. Een e-mailadres wordt nooit geblokkeerd door die beperking: mislukte pogingen worden per adres geteld en gewist door een geslaagde. Na tien binnen een kwartier moet de volgende poging een proof-of-work meesturen, in plaats van dat hij wordt geweigerd. Niemand kan u dus buitensluiten door op uw adres te gokken.
Vergeleken met alternatieven
De meeste diensten voor versleutelde bestandsoverdracht werken met een wachtwoord, met tweestapsverificatie als optie erbij. Paramant draait dat om. TOTP is vanaf de eerste dag verplicht voor mensen. Er is vrijwel niets om inloggegevens mee te stelen, want er valt niets te phishen, uit te proberen of te herstellen.
Uw authenticator instellen → Wanneer een API-sleutel en wanneer TOTP → Reservecodes →
Sleutelcontrole in vier lagen
De relay verspreidt publieke sleutels. Een aanvaller die de relay in handen heeft, zou verkeerde sleutels kunnen uitgeven. Deze vier lagen voorkomen dat:
| Laag | Werking | Beschermt tegen |
|---|---|---|
| 1 · TOFU | De vingerafdruk van het eerste gebruik wordt lokaal bewaard. Elke volgende keer moet die overeenkomen. | Sleutelwissel na het eerste contact |
| 2 · Buiten Paramant om | Beide partijen berekenen dezelfde SHA-256-vingerafdruk en vergelijken die via telefoon, Signal of QR-code. | MITM door de relay bij het eerste contact |
| 3 · PSS | De ontvanger bewijst een gedeeld wachtwoord te kennen voordat de relay zijn sleutels aan de sessie koppelt. Het gaat niet mee in de versleuteling. | Sleutelinjectie door een buitenstaander. Niet door de relay zelf, die het wachtwoord leest bij het aansluiten |
| 4 · CT-log + ML-DSA-65 | Sleutelregistraties worden ondertekend en aan een Merkle-keten toegevoegd. Wie er achteraf een tussenvoegt, spreekt elke ondertekende tree head van daarvoor tegen. Dat ziet iedereen die er een heeft bewaard. | Sleutelinjectie, fraude met tijdstempels |
Een kwetsbaarheid melden
Meld het bij privacy@paramant.app, versleuteld met onze PGP-sleutel als de details gevoelig zijn. Open pas een openbare GitHub-issue als we dat samen hebben afgesproken.
Vingerafdruk van de PGP-sleutel (controleer die voordat u versleutelt):09AA 452A 69DE F4A4 EB4B 72DC 5A34 D82F DAF3 54CD
Wat we vragen
Maak niets openbaar voordat wij een redelijke kans hadden om het op te lossen. Bekijk of wijzig geen gegevens die niet van u zijn. Draai geen geautomatiseerde scans op een schaal die de dienst verstoort. Meld het eerst bij ons, niet bij derden.
Reikwijdte
Binnen de reikwijdte: paramant.app, *.paramant.app, browserextensies die wij publiceren, API-endpoints op docs/api.
Buiten de reikwijdte: social engineering, fysieke aanvallen, denial of service, diensten van derden (Resend, Hetzner, Bunny, Mollie).
Beloning
Een geldbeloning is er nu niet. Wel een vermelding op onze pagina met dankbetuigingen, en voorrang bij nieuwe functies.
Openheid naar klanten
Beveiliging gaat ook over weten wat de leverancier wel en niet kan. De pagina Vertrouwen en controle legt in gewone taal uit hoe de licentiecontrole werkt, wat Paramant van uw relay kan zien (en wat nooit), hoe u uw installatie controleert, en welke acties op afstand mogelijk zijn en welke door de bouw onmogelijk. Elke bewering daar is gemarkeerd als nu actief of gepland, met links naar de openbare protocolspecificaties.
Wat nu
Elk plan krijgt wat deze pagina beschrijft. Community is gratis, voor altijd, zonder betaalkaart. Met het kantoorplan koopt u hogere limieten, geen betere versleuteling.