Comment fonctionne le chiffrement

SG/Send utilise le chiffrement symétrique AES-256-GCM, réalisé entièrement dans votre navigateur. Le serveur ne voit jamais vos données en clair, vos noms de fichiers ni vos clés de chiffrement. Cette page explique exactement comment.

Chiffrement symétrique : une clé, deux opérations

SG/Send utilise le chiffrement symétrique — la même clé chiffre et déchiffre le fichier. C'est le modèle de chiffrement le plus simple et le plus rapide, et lorsqu'il est bien mis en oeuvre, le plus sûr pour le transfert de fichiers.

Qu'est-ce que AES-256-GCM ?

AES (Advanced Encryption Standard) est l'algorithme de chiffrement utilisé par les gouvernements, les banques et les armées du monde entier. 256 est la taille de la clé en bits — il y a 2256 clés possibles, rendant la force brute informatiquement impossible. GCM (Galois/Counter Mode) ajoute le chiffrement authentifié — il ne se contente pas de chiffrer, il détecte également si quelqu'un a altéré le texte chiffré.

Pourquoi le chiffrement symétrique ?

Le chiffrement symétrique utilise une seule clé pour le chiffrement et le déchiffrement. Cela diffère du chiffrement asymétrique (comme RSA) qui utilise une paire de clés. Pour le transfert de fichiers, le symétrique est le bon choix : c'est rapide, bien compris, et la Web Crypto API fournit une implémentation éprouvée dans chaque navigateur moderne.

Le point clé : si vous contrôlez où la clé est générée et où elle circule, le chiffrement symétrique vous offre une confidentialité parfaite. SG/Send génère la clé dans votre navigateur, et la clé ne touche jamais le serveur.

Le flux de chiffrement : étape par étape

Voici exactement ce qui se passe quand vous envoyez un fichier via SG/Send.

1

Génération de clé

Quand vous sélectionnez un fichier, votre navigateur génère une clé AES aléatoire de 256 bits via la Web Crypto API (crypto.subtle.generateKey). Cela utilise le générateur de nombres aléatoires cryptographiquement sûr du système d'exploitation. La clé n'existe que dans la mémoire de votre navigateur.

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

Génération de l'IV

Un vecteur d'initialisation (IV) de 12 octets est généré aléatoirement (crypto.getRandomValues). L'IV garantit que le chiffrement du même fichier deux fois produit un texte chiffré différent. L'IV n'est pas secret — il est préfixé à la sortie chiffrée et envoyé avec le texte chiffré.

3

Chiffrement

Le fichier est chiffré dans le navigateur avec crypto.subtle.encrypt en utilisant l'algorithme AES-GCM, la clé générée et l'IV. La sortie est un texte chiffré + un tag d'authentification de 128 bits. Le tag d'authentification est la garantie d'intégrité du GCM — si quelqu'un modifie ne serait-ce qu'un bit du texte chiffré, le déchiffrement échouera.

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

Téléversement

Seule la sortie chiffrée (IV + texte chiffré + tag d'authentification) est téléversée vers le serveur. Le serveur reçoit un blob d'octets d'apparence aléatoire. Il attribue un identifiant de transfert (12 caractères aléatoires) et stocke le texte chiffré. Pas de nom de fichier, pas d'indication de type de contenu, pas de clé — uniquement des octets chiffrés.

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

Partage du lien

L'expéditeur obtient un lien de téléchargement. La clé de déchiffrement est placée dans le fragment d'URL (la partie après #). Les fragments d'URL ne sont jamais envoyés au serveur par le navigateur — cela est défini dans la RFC 3986. L'expéditeur partage ce lien par le canal de son choix (email, chat, en personne).

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

Déchiffrement

Le destinataire ouvre le lien. Son navigateur télécharge les octets chiffrés depuis le serveur, extrait la clé du fragment d'URL, sépare l'IV du texte chiffré et déchiffre avec crypto.subtle.decrypt. Si le tag d'authentification ne correspond pas (falsification détectée), le déchiffrement échoue. Le serveur ne participe jamais au déchiffrement.

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

Ce que le serveur voit vs. ce qu'il ne voit pas

C'est la garantie de connaissance nulle. Voici exactement quelles données existent sur le serveur.

Le serveur stocke

Identifiant de transfert — 12 caractères aléatoires
Octets chiffrés — indiscernables de données aléatoires
Hash IP — SHA-256 de l'IP + sel rotatif quotidien
Horodatage — date de création du transfert
Taille du fichier — taille du blob chiffré (octets)

Le serveur ne voit jamais

Clé de chiffrement — reste dans le navigateur, partagée via le fragment d'URL
Nom de fichier — jamais envoyé au serveur
Type de fichier — aucune métadonnée content-type stockée
Contenu en clair — seul le texte chiffré est téléversé
Adresse IP brute — hachée avant stockage

Une compromission complète du serveur — accès total à la base de données, toutes les sauvegardes, tous les journaux — ne révèle rien sur le contenu des fichiers transférés. Le texte chiffré est informatiquement indiscernable de bruit aléatoire sans la clé.

Pile technologique

Chaque couche est choisie pour la simplicité, la sécurité et un déploiement sans dépendances.

Couche Technologie Objectif
Runtime Python 3.12 / arm64 Langage du serveur d'application
Framework web FastAPI via osbot-fast-api Routage HTTP et traitement des requêtes
Calcul AWS Lambda + Mangum Exécution serverless, paiement à l'usage
Stockage Memory-FS (Storage_FS) Backend enfichable : mémoire, disque ou S3
Chiffrement Web Crypto API (AES-256-GCM) Chiffrement côté client dans le navigateur
Système de types Type_Safe (osbot-utils) Définitions de schémas sans Pydantic
Frontend Vanilla JS + Web Components Zéro dépendance de framework (IFD)
Tests pytest, pile en mémoire Pas de mocks, pas de patches, des implémentations réelles
CI/CD GitHub Actions Pipeline de test, tag et déploiement

Architecture du système

Deux fonctions Lambda, une couche de stockage, un CDN. Simple par conception.

Lambda Utilisateur (Publique)

Fonction publique qui gère les transferts de fichiers, les contrôles de santé, les téléversements présignés, les coffres-forts personnels et l'intégration MCP. Accessible via Lambda Function URL derrière CloudFront.

18 points de terminaison

Lambda Admin (Authentifiée)

Fonction réservée à l'administration pour la gestion des jetons, l'analytique, les statistiques serveur et les outils MCP admin. Nécessite une authentification. Lambda séparée = frontière de sécurité séparée.

55 points de terminaison

Memory-FS (Storage_FS)

Tout le stockage passe par une couche d'abstraction. Le code applicatif ne sait jamais si le backend est en mémoire, sur disque ou sur S3. Même base de code sur les 7 cibles de déploiement.

Backend enfichable

CloudFront CDN

Ressources statiques, mise en cache, terminaison SSL et WAF. Les Lambda URLs fournissent les points de terminaison HTTPS directement — sans API Gateway.

Réseau périphérique

Cibles de déploiement

Une base de code, sept cibles de déploiement regroupées en quatre modèles.

Lambda

Déploiement principal. Deux fonctions Lambda derrière des Lambda Function URLs. Points de terminaison HTTPS directs, sans API Gateway.

Production

Conteneur

Docker, AWS Fargate et GCP Cloud Run. La même application conditionnée en conteneur.

Docker / Fargate / GCP

Serveur

Instances EC2 et builds AMI. Pour les équipes qui ont besoin d'un contrôle total de l'environnement d'exécution.

EC2 / AMI

CLI

Interface en ligne de commande pour les transferts scriptés, les pipelines CI/CD et les utilisateurs avancés.

Terminal
18
Agents IA
73
Points de terminaison HTTP
393
Tests réussis
7
Cibles de déploiement
Voir le code source sur GitHub →