CoffreZero
Un coffre-fort de documents à chiffrement zero-knowledge où le serveur est mathématiquement incapable de lire vos données — construit avec XChaCha20-Poly1305 côté client, dérivation de clés Argon2id et architecture SDK-first.
Démo frontend — l'infrastructure backend n'est pas déployée pour cette vitrine
Résultats clés
Modèle de chiffrement
Zero-knowledge
Le serveur ne stocke que du texte chiffré — il est mathématiquement impossible de lire le texte en clair sans la clé utilisateur.
Dérivation de clé
Argon2id
Paramètres recommandés par l'OWASP : m=65536, t=3, p=4 pour la résistance au brute-force.
Infrastructure
7 containers
PostgreSQL, Redis, MinIO, FastAPI, worker ARQ, Next.js, Nginx — entièrement conteneurisé.
Couverture SDK
2 SDKs
SDK TypeScript et Python avec authentification, documents, partage, secrets éphémères et API développeur.
Le problème
Ce que ce projet devait résoudre
La plupart des solutions de stockage de documents chiffrent les données au repos côté serveur — ce qui signifie que le fournisseur peut tout lire. CoffreZero élimine entièrement cette hypothèse de confiance grâce au chiffrement zero-knowledge côté client.
CoffreZero a été conçu autour d'un principe non négociable : le serveur ne doit jamais avoir la capacité de déchiffrer les documents stockés. Tout le chiffrement s'effectue côté client avec le chiffrement AEAD XChaCha20-Poly1305 de libsodium, les clés maîtres étant dérivées des mots de passe utilisateur via Argon2id (paramètres OWASP).
Le backend est un service asynchrone FastAPI avec PostgreSQL, Redis, MinIO (stockage compatible S3) et des workers en arrière-plan ARQ. Le frontend est construit sur Next.js 14 avec gestion d'état Zustand, visualisation 3D Three.js et Framer Motion. Deux SDK (TypeScript et Python) offrent un accès programmatique avec prise en charge complète des webhooks HMAC-SHA256.
Ce qui distingue CoffreZero, c'est la profondeur du modèle de sécurité : des DEK aléatoires par document enveloppées avec NaCl SecretBox, le partage via sealed-box pour les destinataires, des journaux d'audit chaînés HMAC-SHA256 pour la détection de falsification, des secrets éphémères à lecture unique, un protocole d'effacement RGPD Article 17 et un watermarking forensique pour la détection de fuites.
Ce qui a changé
Les utilisateurs disposent d'un coffre-fort documentaire où le partage, l'audit et la collaboration fonctionnent de manière fluide — mais le fournisseur est cryptographiquement exclu. La souveraineté des données devient une propriété démontrable, et non une simple promesse marketing.
Pourquoi c'était difficile
Le défi consistait à rendre le chiffrement zero-knowledge transparent dans l'interface tout en maintenant des garanties cryptographiques rigoureuses : des DEK par document, un re-chiffrement sealed-box pour le partage et des pistes d'audit chaînées HMAC capables de résister même en cas de compromission de la base de données.
Contraintes
- Toutes les opérations cryptographiques doivent se dérouler dans le navigateur — le serveur ne voit jamais le texte en clair ni les clés maîtres.
- Le partage de documents nécessite un re-chiffrement des DEK pour les destinataires sans exposer le texte en clair à aucun intermédiaire.
- Le journal d'audit doit être cryptographiquement inviolable grâce à l'intégrité de chaîne HMAC-SHA256.
Mon rôle
- Conception de l'architecture cryptographique complète : hiérarchie de clés, enveloppement des DEK, partage par sealed-box.
- Construction du backend FastAPI avec PostgreSQL asynchrone, cache Redis, stockage objet MinIO et workers ARQ.
- Implémentation de la couche de chiffrement côté client avec libsodium WASM (XChaCha20-Poly1305, Argon2id, NaCl boxes).
- Création des SDK TypeScript et Python avec livraison de webhooks et vérification de signature HMAC.
Preuves
À quoi ressemble réellement le produit
Captures d'écran réelles du produit — chacune illustre un argument concret de clarté, de contrôle ou d'observabilité.
Surface de marqueCliquer pour agrandirPage d'accueil
Une page d'accueil propulsée par Three.js qui communique le chiffrement zero-knowledge et l'architecture SDK-first.
La visualisation 3D renforce le discours sécuritaire tandis que le message produit reste concret.
Produit principalCliquer pour agrandirCoffre-fort documentaire
Le coffre-fort chiffré où les documents sont stockés, organisés et gérés avec un déchiffrement intégralement côté client.
Les documents ne sont déchiffrés dans le navigateur que lorsque l'utilisateur en demande explicitement l'accès.
CollaborationCliquer pour agrandirPartage sécurisé
Partage de documents à durée limitée et à finalité spécifique, avec re-chiffrement sealed-box pour les destinataires.
La DEK est re-chiffrée pour le destinataire à l'aide de sa clé publique — le serveur ne voit jamais la clé en clair.
ÉphémèreCliquer pour agrandirSecrets éphémères
Des secrets à usage unique avec protection optionnelle par phrase de passe et expiration automatique.
Chiffrement XChaCha20-Poly1305 avec limites d'accès configurables et destruction programmée.
IntégritéCliquer pour agrandirPiste d'audit
Journal d'audit chaîné HMAC-SHA256 qui détecte toute falsification grâce à la vérification cryptographique de la chaîne.
Chaque entrée inclut le previous_hash, l'action, l'actor_id, le hash de l'IP et l'horodatage dans une chaîne immuable.
Décisions
Les compromis qui ont façonné le produit
Le travail le plus solide se révèle dans les choix faits sous pression, pas seulement dans l'interface finale.
Chiffrement côté client plutôt que chiffrement au repos côté serveur
Défi
Le chiffrement côté serveur permet toujours au fournisseur de lire les données. Le zero-knowledge exige une architecture fondamentalement différente.
Décision
Tout le chiffrement et déchiffrement s'effectue dans le navigateur via libsodium WASM. Les clés maîtres sont dérivées localement via Argon2id et ne sont jamais transmises.
Compromis
La recherche et l'indexation côté serveur deviennent impossibles, mais la garantie de sécurité est mathématiquement démontrable.
XChaCha20-Poly1305 plutôt qu'AES-256-GCM
Défi
AES-GCM présente un risque catastrophique de réutilisation de nonce avec son nonce de 96 bits. Des volumes élevés de documents augmentent la probabilité de collision.
Décision
XChaCha20-Poly1305 avec des nonces de 192 bits élimine le risque de collision de nonce même à très grande échelle.
Compromis
Légèrement moins d'accélération matérielle qu'AES-GCM, mais la marge de sécurité en vaut la peine pour un coffre-fort documentaire.
Conception API SDK-first plutôt que produit exclusivement UI
Défi
Les clients entreprise ont besoin d'un accès programmatique pour l'automatisation, les workflows de conformité et l'intégration.
Décision
Les SDK TypeScript et Python ont été construits en parallèle du produit avec parité API complète, livraison de webhooks et vérification de signature HMAC-SHA256.
Compromis
La surface à maintenir est doublée, mais cela ouvre l'adoption par les développeurs et les scénarios d'intégration.
Architecture
Comment les données circulent dans le système
Authentification
L'utilisateur se connecte ; le mot de passe est vérifié côté serveur avec Argon2id. La clé maître est dérivée côté client à partir du mot de passe et du sel KDF.
→ La clé maître n'existe que dans la mémoire du navigateur — jamais transmise, jamais stockée.
Chiffrement et téléversement
Une DEK aléatoire de 32 octets est générée par document. Le fichier est chiffré avec XChaCha20-Poly1305. La DEK est enveloppée avec NaCl SecretBox à l'aide de la clé maître.
→ Le serveur ne reçoit que du texte chiffré et une DEK enveloppée qu'il ne peut pas déballer.
Stockage
Le fichier chiffré est envoyé vers MinIO (compatible S3). La DEK enveloppée et les métadonnées sont stockées dans PostgreSQL. L'entrée d'audit est chaînée par HMAC.
→ Les données au repos sont du texte chiffré sur l'ensemble des couches de stockage.
Partage
Le propriétaire déchiffre la DEK côté client et la re-chiffre pour le destinataire en utilisant sa clé publique via NaCl sealed box.
→ Le destinataire peut déchiffrer sans que le serveur ne voie jamais la DEK en clair.
Audit et conformité
Chaque action est enregistrée dans une chaîne HMAC-SHA256. Les demandes d'effacement au titre de l'Article 17 du RGPD déclenchent des workflows de suppression cryptographique.
→ La conformité est démontrable par l'intégrité cryptographique de la chaîne, et non par de simples documents de politique.
CoffreZero utilise une architecture zero-knowledge où tout le chiffrement s'effectue côté client via libsodium WASM. Le backend FastAPI gère l'authentification, les métadonnées et l'orchestration mais ne voit jamais le texte en clair. PostgreSQL stocke les métadonnées chiffrées et les DEK enveloppées, MinIO stocke les blobs de texte chiffré, Redis gère les sessions et les files de tâches, et les workers ARQ traitent les tâches asynchrones comme l'application des expirations et la livraison des webhooks. Le frontend dérive les clés maîtres localement via Argon2id et gère toutes les opérations cryptographiques dans la mémoire du navigateur.
Surfaces produit
Les interfaces qui portent l'expérience
Coffre-fort Zero-Knowledge
Stockage de documents chiffré où toutes les opérations cryptographiques se déroulent côté client. Le serveur ne stocke que du texte chiffré.
Partage sécurisé de documents
Partage à durée limitée et à finalité spécifique avec re-chiffrement sealed-box — aucun texte en clair ne touche jamais le serveur.
Partage rapide par QR Code
Génération de QR codes pour un partage instantané de documents avec identifiants d'accès intégrés et limites de temps.
Secrets à lecture unique
Messages chiffrés éphémères avec protection optionnelle par phrase de passe, limites d'accès et destruction automatique.
Piste d'audit cryptographique
Journal d'audit chaîné HMAC-SHA256 où chaque entrée référence le hash précédent — toute falsification brise la chaîne.
Souveraineté des données et RGPD
Déploiement auto-hébergeable avec protocole de droit à l'oubli au titre de l'Article 17 du RGPD et suppression cryptographique.
API développeur et SDK
SDK TypeScript et Python avec parité API complète, webhooks signés HMAC et gestion d'erreurs exhaustive.
Identité CoffreZero
Génération d'identité décentralisée (DID) avec paires de clés de signature Ed25519 et vérification multi-niveaux.
Stack technique
Construit avec
FastAPI
Framework API Python asynchrone
PostgreSQL
Base de données relationnelle principale
Redis
Cache, stockage de sessions, file de tâches
Framework
UI
Data
Infra
Langages
TypeScriptPythonSQLCSS/TailwindCe que ce projet démontre