Votre coffre-fort numérique.
Vos fichiers, rien qu'à vous.
CryptoSAS chiffre vos fichiers directement dans votre navigateur.
Seul vous possédez la clé. Même nous ne pouvons pas lire vos données.
Sécurité maximum. Par conception.
Zero-Knowledge
Vos fichiers sont chiffrés dans votre navigateur avant d'être envoyés. Le serveur ne stocke que des données illisibles.
Votre clé, votre contrôle
Nous ne stockons jamais votre mot de passe de chiffrement. Si vous l'oubliez, personne ne peut récupérer vos fichiers — pas même nous.
Gestionnaire de fichiers
Interface intuitive type explorateur de fichiers. Organisez vos documents en dossiers, téléchargez et déchiffrez en un clic.
Double authentification
Protégez votre compte avec la 2FA TOTP compatible Google Authenticator, Authy et toutes les applications standard.
API sécurisée
Intégrez CryptoSAS dans vos workflows via notre API REST TLS 1.3. Clés API scopées, chiffrement client ou délégué au serveur selon vos besoins.
Suivi du stockage
Visualisez votre utilisation en temps réel. Quotas configurables, facturation transparente à l'usage.
Empreinte & Horodatage
Chaque fichier reçoit une empreinte SHA-256 calculée avant chiffrement, dans votre navigateur. Preuve d'antériorité, intégrité garantie.
Comment ça fonctionne
Choisissez un fichier
Sélectionnez ou glissez-déposez vos fichiers dans l'interface.
Empreinte & chiffrement
Votre navigateur calcule l'empreinte SHA-256 du fichier original,
puis le chiffre avec AES-256-GCM.
Mot de passe et contenu ne quittent jamais votre appareil.
Stockage sécurisé
Le blob chiffré et l'empreinte sont envoyés sur nos serveurs.
Le fichier est illisible sans votre clé — l'empreinte reste disponible
pour l'horodatage.
Deux modes d'intégration
CryptoSAS s'adapte à vos contraintes techniques. Choisissez le niveau de protection qui correspond à votre architecture.
Chiffrement côté client
Le chiffrement et le déchiffrement s'effectuent exclusivement dans le navigateur ou dans votre application cliente. Le serveur ne voit jamais le contenu, ni la clé, ni le mot de passe.
- ✅ Serveur ne voit jamais le contenu
- ✅ Clé et mot de passe jamais transmis
- ✅ Fichiers illisibles en cas de compromission serveur
- ✅ Conforme aux exigences les plus strictes (RGPD, secret professionnel)
- ✅ Empreinte SHA-256 calculée avant chiffrement
POST /api/v1/files avec blob pré-chiffré
Chiffrement délégué au serveur
Le serveur prend en charge le chiffrement et le déchiffrement via l'API. Le fichier transite en clair vers le serveur (TLS uniquement) et est traité en mémoire — jamais stocké en clair.
- ✅ Fichier stocké chiffré sur disque — illisible au repos
- ✅ Clé jamais persistée — dérivée à la volée, effacée après usage
- ✅ Même algorithme que le mode client (interopérable)
- ⚠️ Serveur voit le contenu en mémoire pendant l'opération
- ⚠️ Mot de passe transmis dans le corps de la requête (TLS protégé)
POST /api/v1/files/upload-plain et
POST /api/v1/files/{id}/decrypt
Vos données ne voyagent jamais en clair sur le réseau. TLS 1.3 (RFC 8446) chiffre l'intégralité de la connexion, y compris les en-têtes HTTP.
- Perfect Forward Secrecy (PFS) Chaque session génère une clé de session éphémère via ECDHE. Même si la clé privée du serveur était compromise des années plus tard, les sessions passées restent mathématiquement indéchiffrables.
- Suites cryptographiques modernes uniquement TLS 1.3 supprime tous les algorithmes faibles : RSA statique, RC4, DES, 3DES, MD5, SHA-1. Seules AES-256-GCM et ChaCha20-Poly1305 sont acceptées — deux algorithmes de chiffrement authentifié (AEAD).
-
HSTS — Impossible de forcer le HTTP
L'en-tête
Strict-Transport-Securityavecmax-age=31536000interdit au navigateur toute connexion non chiffrée, bloquant les attaques de type downgrade et man-in-the-middle. - Handshake en 1 aller-retour (1-RTT) TLS 1.3 réduit le handshake à 1-RTT contre 2-RTT pour TLS 1.2, supprimant les messages non chiffrés de la phase de négociation et réduisant la surface d'attaque dès l'établissement de la connexion.
Le fichier n'est présent en clair qu'en RAM pendant quelques millisecondes, dans un espace mémoire protégé par l'OS, et n'est jamais écrit sur le disque.
- Isolation des processus par l'OS Linux isole l'espace d'adressage de chaque processus (virtual address space). Aucun autre processus — ni un intrus ayant accès à la machine — ne peut lire la mémoire d'un processus actif sans privilèges noyau root.
- ASLR + DEP/NX — Protection contre l'exploitation L'Address Space Layout Randomization randomise les adresses mémoire à chaque démarrage. Le bit NX (No-Execute) empêche l'exécution de code injecté en mémoire. Ces deux mécanismes rendent l'exploitation d'une vulnérabilité mémoire extrêmement difficile.
- Aucune écriture disque du plaintext Seul le blob chiffré AES-256-GCM est persisté sur le disque. Le fichier original et la clé dérivée ne quittent jamais la RAM — ils sont libérés par PHP dès la fin de l'opération cryptographique.
- Fenêtre d'exposition de quelques millisecondes La durée pendant laquelle le plaintext existe en mémoire est limitée au temps d'exécution de PBKDF2 + AES-GCM, soit quelques dizaines de millisecondes. Une attaque de type cold-boot requiert un accès physique immédiat au serveur — hors du modèle de menace d'une API distante.
Commencez gratuitement
5 Go de stockage sécurisé inclus. Aucune carte bancaire requise.
Créer mon coffre-fort