Hoe de versleuteling werkt

SG/Send gebruikt AES-256-GCM symmetrische versleuteling, volledig uitgevoerd in uw browser. De server ziet nooit uw onversleutelde gegevens, uw bestandsnamen of uw versleutelingssleutels. Deze pagina legt precies uit hoe het werkt.

Symmetrische versleuteling: één sleutel, twee bewerkingen

SG/Send gebruikt symmetrische versleuteling — dezelfde sleutel versleutelt en ontsleutelt het bestand. Dit is het eenvoudigste en snelste versleutelingsmodel en, mits correct uitgevoerd, het veiligste voor bestandsoverdracht.

Wat is AES-256-GCM?

AES (Advanced Encryption Standard) is het versleutelingsalgoritme dat wordt gebruikt door overheden, banken en legers wereldwijd. 256 is de sleutelgrootte in bits — er zijn 2256 mogelijke sleutels, waardoor brute force computationeel onmogelijk is. GCM (Galois/Counter Mode) voegt geauthenticeerde versleuteling toe — het versleutelt niet alleen, maar detecteert ook of iemand de cijfertekst heeft gemanipuleerd.

Waarom symmetrisch?

Symmetrische versleuteling gebruikt één sleutel voor zowel versleuteling als ontsleuteling. Dit verschilt van asymmetrische versleuteling (zoals RSA) die een sleutelpaar gebruikt. Voor bestandsoverdracht is symmetrisch de juiste keuze: het is snel, goed begrepen en de Web Crypto API biedt een beproefde implementatie in elke moderne browser.

Het belangrijkste inzicht: als u bepaalt waar de sleutel wordt gegenereerd en waar deze naartoe gaat, biedt symmetrische versleuteling u perfecte vertrouwelijkheid. SG/Send genereert de sleutel in uw browser en de sleutel raakt nooit de server.

De versleutelingsstroom: stap voor stap

Dit is precies wat er gebeurt wanneer u een bestand verstuurt via SG/Send.

1

Sleutelgeneratie

Wanneer u een bestand selecteert, genereert uw browser een willekeurige 256-bits AES-sleutel met behulp van de Web Crypto API (crypto.subtle.generateKey). Dit gebruikt de cryptografisch veilige willekeurige nummergenerator van het besturingssysteem. De sleutel bestaat alleen in het geheugen van uw browser.

Browser Server | | | crypto.subtle.generateKey( | | { name: "AES-GCM", length: 256 }, | | true, | | ["encrypt", "decrypt"] | | ) | | | | Key generated: 3a7f...b2c1 (256 bits) | | Key stays here. Server knows nothing. | | |
2

IV-generatie

Een 12-byte initialisatievector (IV) wordt willekeurig gegenereerd (crypto.getRandomValues). De IV zorgt ervoor dat het tweemaal versleutelen van hetzelfde bestand verschillende cijfertekst oplevert. De IV is niet geheim — deze wordt vooraan de versleutelde uitvoer geplaatst en met de cijfertekst meegestuurd.

3

Versleuteling

Het bestand wordt in de browser versleuteld met crypto.subtle.encrypt met het AES-GCM-algoritme, de gegenereerde sleutel en de IV. De uitvoer is cijfertekst + een 128-bits authenticatietag. De authenticatietag is de integriteitsgarantie van GCM — als iemand ook maar één bit van de cijfertekst wijzigt, mislukt de ontsleuteling.

Browser Server | | | plaintext ──► AES-256-GCM ──► ciphertext | | ▲ | | | | | key + IV | | | | Output = IV (12 bytes) | | + ciphertext (same size as plaintext) | | + auth tag (16 bytes) | | |
4

Uploaden

Alleen de versleutelde uitvoer (IV + cijfertekst + authenticatietag) wordt naar de server geüpload. De server ontvangt een blob van willekeurig ogende bytes. Het wijst een overdrachts-ID toe (12 willekeurige tekens) en slaat de cijfertekst op. Geen bestandsnaam, geen content-type-hint, geen sleutel — alleen versleutelde bytes.

Browser Server | | | POST /transfers/create | | ──────────────────────────────────────────► | | | Stores: | PUT /transfers/{id}/upload | transfer_id: "a7x9k2m4p1" | Body: [IV + ciphertext + auth tag] | data: [encrypted bytes] | ──────────────────────────────────────────► | ip_hash: SHA256(ip + salt) | | timestamp: 2026-02-28T... | Key NEVER sent. File name NEVER sent. | | |
5

Link delen

De verzender ontvangt een downloadlink. De ontsleutelingssleutel wordt in het URL-fragment geplaatst (het deel na #). URL-fragmenten worden nooit door de browser naar de server gestuurd — dit is gedefinieerd in RFC 3986. De verzender deelt deze link via elk kanaal naar keuze (e-mail, chat, persoonlijk).

Link format: https://send.sgraph.ai/download/a7x9k2m4p1#3a7f...b2c1 ├──────────── domain ────────────┤├─ transfer id ─┤├─ key ─┤ ▲ │ URL fragment (#) Never sent to server Stays in the browser
6

Ontsleuteling

De ontvanger opent de link. Hun browser downloadt de versleutelde bytes van de server, haalt de sleutel uit het URL-fragment, scheidt de IV van de cijfertekst en ontsleutelt met crypto.subtle.decrypt. Als de authenticatietag niet overeenkomt (manipulatie gedetecteerd), mislukt de ontsleuteling. De server neemt nooit deel aan de ontsleuteling.

Recipient's Browser Server | | | GET /transfers/{id}/download | | ──────────────────────────────────────────► | | ◄────────────────────────────────────────── | | Response: [IV + ciphertext + auth tag] | | | | Key extracted from URL fragment (#) | | crypto.subtle.decrypt( | | { name: "AES-GCM", iv: IV }, | | key, | | ciphertext | | ) | | | | ──► plaintext file restored | | Server never saw the key or the plaintext. |

Wat de server ziet vs. wat deze niet ziet

Dit is de zero-knowledge-garantie. Hier is precies welke gegevens op de server bestaan.

De server slaat op

Overdrachts-ID — willekeurige 12 tekens
Versleutelde bytes — niet te onderscheiden van willekeurige gegevens
IP-hash — SHA-256 van IP + dagelijks roterend salt
Tijdstempel — wanneer de overdracht is aangemaakt
Bestandsgrootte — grootte van de versleutelde blob (bytes)

De server ziet nooit

Versleutelingssleutel — blijft in de browser, gedeeld via URL-fragment
Bestandsnaam — wordt nooit naar de server gestuurd
Bestandstype — geen content-type-metadata opgeslagen
Onversleutelde inhoud — alleen cijfertekst wordt geüpload
Onbewerkt IP-adres — gehasht vóór opslag

Een volledig servercompromis — volledige databasetoegang, alle back-ups, alle logboeken — onthult niets over de inhoud van overgedragen bestanden. De cijfertekst is computationeel niet te onderscheiden van willekeurige ruis zonder de sleutel.

Technologiestack

Elke laag is gekozen voor eenvoud, beveiliging en implementatie zonder afhankelijkheden.

Laag Technologie Doel
Runtime Python 3.12 / arm64 Applicatieservertaal
Webframework FastAPI via osbot-fast-api HTTP-routing en verwerking van verzoeken
Compute AWS Lambda + Mangum Serverloze uitvoering, betalen per gebruik
Opslag Memory-FS (Storage_FS) Uitwisselbare backend: geheugen, schijf of S3
Versleuteling Web Crypto API (AES-256-GCM) Clientzijde versleuteling in de browser
Typesysteem Type_Safe (osbot-utils) Schemadefinities zonder Pydantic
Frontend Vanilla JS + Web Components Nul frameworkafhankelijkheden (IFD)
Testen pytest, in-memory stack Geen mocks, geen patches, echte implementaties
CI/CD GitHub Actions Test-, tag- en implementatiepijplijn

Systeemarchitectuur

Twee Lambda-functies, één opslaglaag, één CDN. Eenvoudig door ontwerp.

User Lambda (Publiek)

Publieke functie die bestandsoverdrachten, gezondheidscontroles, vooraf ondertekende uploads, persoonlijke kluizen en MCP-integratie afhandelt. Toegankelijk via Lambda Function URL achter CloudFront.

18 eindpunten

Admin Lambda (Geauthenticeerd)

Alleen-admin-functie voor tokenbeheer, analyses, serverstatistieken en MCP-beheertools. Vereist authenticatie. Aparte Lambda = aparte beveiligingsgrens.

55 eindpunten

Memory-FS (Storage_FS)

Alle opslag gaat via een abstractielaag. Applicatiecode weet nooit of de backend in het geheugen, op schijf of S3 is. Dezelfde codebase over alle 7 implementatiedoelen zonder een regel applicatielogica te wijzigen.

Uitwisselbare backend

CloudFront CDN

Statische assets, caching, SSL-terminatie en WAF. Lambda URLs bieden de HTTPS-eindpunten rechtstreeks — geen API Gateway nodig.

Edge-netwerk

Implementatiedoelen

Eén codebase, zeven implementatiedoelen gegroepeerd in vier patronen.

Lambda

Primaire implementatie. Twee Lambda-functies achter Lambda Function URLs. Directe HTTPS-eindpunten, geen API Gateway nodig.

Productie

Container

Docker, AWS Fargate en GCP Cloud Run. Dezelfde applicatie verpakt als container.

Docker / Fargate / GCP

Server

EC2-instanties en AMI-builds. Voor teams die volledige controle over de runtime-omgeving nodig hebben.

EC2 / AMI

CLI

Opdrachtregelinterface voor gescripte overdrachten, CI/CD-pijplijnen en gevorderde gebruikers.

Terminal
18
AI-agents
73
HTTP-eindpunten
393
Geslaagde tests
7
Implementatiedoelen
Bekijk broncode op GitHub →