Wie die Verschlüsselung funktioniert

SG/Send verwendet symmetrische AES-256-GCM-Verschlüsselung, die vollständig in Ihrem Browser durchgeführt wird. Der Server sieht niemals Ihre Klartextdaten, Ihre Dateinamen oder Ihre Verschlüsselungsschlüssel. Diese Seite erklärt genau, wie das funktioniert.

Symmetrische Verschlüsselung: Ein Schlüssel, zwei Operationen

SG/Send verwendet symmetrische Verschlüsselung — derselbe Schlüssel verschlüsselt und entschlüsselt die Datei. Dies ist das einfachste und schnellste Verschlüsselungsmodell und, wenn korrekt umgesetzt, das sicherste für den Dateitransfer.

Was ist AES-256-GCM?

AES (Advanced Encryption Standard) ist der Verschlüsselungsalgorithmus, der weltweit von Regierungen, Banken und Militärs verwendet wird. 256 ist die Schlüssellänge in Bits — es gibt 2256 mögliche Schlüssel, was Brute Force rechnerisch unmöglich macht. GCM (Galois/Counter Mode) fügt authentifizierte Verschlüsselung hinzu — es verschlüsselt nicht nur, sondern erkennt auch, ob jemand den Chiffretext manipuliert hat.

Warum symmetrisch?

Symmetrische Verschlüsselung verwendet einen Schlüssel sowohl für die Verschlüsselung als auch für die Entschlüsselung. Dies unterscheidet sich von asymmetrischer Verschlüsselung (wie RSA), die ein Schlüsselpaar verwendet. Für den Dateitransfer ist symmetrisch die richtige Wahl: Es ist schnell, gut verstanden, und die Web Crypto API bietet eine kampferprobte Implementierung in jedem modernen Browser.

Die zentrale Erkenntnis: Wenn Sie kontrollieren, wo der Schlüssel generiert wird und wohin er übertragen wird, bietet symmetrische Verschlüsselung perfekte Vertraulichkeit. SG/Send generiert den Schlüssel in Ihrem Browser, und der Schlüssel berührt niemals den Server.

Der Verschlüsselungsablauf: Schritt für Schritt

Hier sehen Sie genau, was passiert, wenn Sie eine Datei über SG/Send senden.

1

Schlüsselgenerierung

Wenn Sie eine Datei auswählen, generiert Ihr Browser einen zufälligen 256-Bit-AES-Schlüssel mit der Web Crypto API (crypto.subtle.generateKey). Dabei wird der kryptographisch sichere Zufallszahlengenerator des Betriebssystems verwendet. Der Schlüssel existiert ausschliesslich im Arbeitsspeicher Ihres Browsers.

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-Generierung

Ein 12-Byte-Initialisierungsvektor (IV) wird zufällig generiert (crypto.getRandomValues). Der IV stellt sicher, dass die zweimalige Verschlüsselung derselben Datei unterschiedlichen Chiffretext erzeugt. Der IV ist nicht geheim — er wird der verschlüsselten Ausgabe vorangestellt und mit dem Chiffretext gesendet.

3

Verschlüsselung

Die Datei wird im Browser mit crypto.subtle.encrypt unter Verwendung des AES-GCM-Algorithmus, des generierten Schlüssels und des IV verschlüsselt. Die Ausgabe ist Chiffretext + ein 128-Bit-Authentifizierungs-Tag. Das Authentifizierungs-Tag ist die Integritätsgarantie von GCM — wenn jemand auch nur ein Bit des Chiffretexts ändert, schlägt die Entschlüsselung fehl.

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

Hochladen

Nur die verschlüsselte Ausgabe (IV + Chiffretext + Auth-Tag) wird auf den Server hochgeladen. Der Server empfängt einen Block zufällig aussehender Bytes. Er weist eine Transfer-ID (12 zufällige Zeichen) zu und speichert den Chiffretext. Kein Dateiname, kein Content-Type-Hinweis, kein Schlüssel — nur verschlüsselte 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-Freigabe

Der Absender erhält einen Download-Link. Der Entschlüsselungsschlüssel wird im URL-Fragment (dem Teil nach #) platziert. URL-Fragmente werden vom Browser niemals an den Server gesendet — dies ist in RFC 3986 definiert. Der Absender teilt diesen Link über einen beliebigen Kanal (E-Mail, Chat, persönlich).

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

Entschlüsselung

Der Empfänger öffnet den Link. Sein Browser lädt die verschlüsselten Bytes vom Server herunter, extrahiert den Schlüssel aus dem URL-Fragment, trennt den IV vom Chiffretext und entschlüsselt mit crypto.subtle.decrypt. Wenn das Auth-Tag nicht übereinstimmt (Manipulation erkannt), schlägt die Entschlüsselung fehl. Der Server ist an der Entschlüsselung niemals beteiligt.

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. |

Was der Server sieht und was nicht

Dies ist die Zero-Knowledge-Garantie. Hier sehen Sie genau, welche Daten auf dem Server existieren.

Der Server speichert

Transfer-ID — zufällige 12 Zeichen
Verschlüsselte Bytes — nicht von zufälligen Daten unterscheidbar
IP-Hash — SHA-256 der IP + täglich rotierendem Salt
Zeitstempel — wann die Übertragung erstellt wurde
Dateigrösse — Grösse des verschlüsselten Blobs (Bytes)

Der Server sieht niemals

Verschlüsselungsschlüssel — verbleibt im Browser, wird über URL-Fragment geteilt
Dateiname — wird niemals an den Server gesendet
Dateityp — keine Content-Type-Metadaten gespeichert
Klartextinhalt — nur Chiffretext wird hochgeladen
Reine IP-Adresse — wird vor der Speicherung gehasht

Eine vollständige Serverkompromittierung — vollständiger Datenbankzugriff, alle Backups, alle Protokolle — enthüllt nichts über den Inhalt der übertragenen Dateien. Der Chiffretext ist ohne den Schlüssel rechnerisch nicht von zufälligem Rauschen zu unterscheiden.

Technologie-Stack

Jede Schicht wurde nach den Kriterien Einfachheit, Sicherheit und abhängigkeitsfreie Bereitstellung ausgewählt.

Schicht Technologie Zweck
Laufzeit Python 3.12 / arm64 Programmiersprache des Anwendungsservers
Web-Framework FastAPI via osbot-fast-api HTTP-Routing und Anfrageverarbeitung
Compute AWS Lambda + Mangum Serverlose Ausführung, nutzungsbasierte Abrechnung
Speicher Memory-FS (Storage_FS) Austauschbares Backend: Arbeitsspeicher, Festplatte oder S3
Verschlüsselung Web Crypto API (AES-256-GCM) Clientseitige Verschlüsselung im Browser
Typsystem Type_Safe (osbot-utils) Schemadefinitionen ohne Pydantic
Frontend Vanilla JS + Web Components Null Framework-Abhängigkeiten (IFD)
Tests pytest, In-Memory-Stack Keine Mocks, keine Patches, echte Implementierungen
CI/CD GitHub Actions Test-, Tag- und Bereitstellungspipeline

Systemarchitektur

Zwei Lambda-Funktionen, eine Speicherschicht, ein CDN. Einfach konstruiert.

User Lambda (öffentlich)

Öffentlich zugängliche Funktion für Dateiübertragungen, Integritätsprüfungen, Presigned-Uploads, persönliche Tresore und MCP-Integration. Zugriff über Lambda Function URL hinter CloudFront.

18 Endpunkte

Admin Lambda (authentifiziert)

Reine Admin-Funktion für Token-Verwaltung, Analysen, Serverstatistiken und MCP-Admin-Tools. Erfordert Authentifizierung. Separates Lambda = separate Sicherheitsgrenze.

55 Endpunkte

Memory-FS (Storage_FS)

Jeder Speicherzugriff erfolgt über eine Abstraktionsschicht. Der Anwendungscode weiss nicht, ob das Backend im Arbeitsspeicher, auf der Festplatte oder in S3 liegt. Dieselbe Codebasis über alle 7 Bereitstellungsziele hinweg.

Austauschbares Backend

CloudFront CDN

Statische Assets, Caching, SSL-Terminierung und WAF. Lambda URLs stellen die HTTPS-Endpunkte direkt bereit — kein API Gateway erforderlich.

Edge-Netzwerk

Bereitstellungsziele

Eine Codebasis, sieben Bereitstellungsziele in vier Mustern gruppiert.

Lambda

Primäre Bereitstellung. Zwei Lambda-Funktionen hinter Lambda Function URLs. Direkte HTTPS-Endpunkte, kein API Gateway erforderlich.

Produktion

Container

Docker, AWS Fargate und GCP Cloud Run. Dieselbe Anwendung als Container verpackt.

Docker / Fargate / GCP

Server

EC2-Instanzen und AMI-Builds. Für Teams, die volle Kontrolle über die Laufzeitumgebung benötigen.

EC2 / AMI

CLI

Kommandozeilenschnittstelle für geskriptete Übertragungen, CI/CD-Pipelines und erfahrene Benutzer.

Terminal
18
KI-Agenten
73
HTTP-Endpunkte
393
Bestandene Tests
7
Bereitstellungsziele
Quellcode auf GitHub ansehen →