Sécurité
Chaque affirmation cryptographique de cette page est auditable dans le code open source. Voici exactement ce que fait StenVault — et pourquoi.
Zero-knowledge
Le serveur ne voit jamais que des octets chiffrés. Les noms de fichiers, le contenu des fichiers et les clés de chiffrement restent sur votre appareil.
Le contenu des fichiers et les noms de fichiers sont chiffrés sur votre appareil avant d'atteindre nos serveurs. Nous ne détenons jamais de texte en clair ni de clés de déchiffrement.
La connexion utilise le protocole OPAQUE (RFC 9807). Votre mot de passe ne quitte jamais votre appareil, et aucun hachage de mot de passe n'est stocké sur le serveur.
Le client complet est public sur GitHub. Chaque affirmation cryptographique de cette page est vérifiable dans le code source.
Robustesse post-quantique
Le NIST définit cinq niveaux de sécurité pour les algorithmes post-quantiques. La plupart des implémentations choisissent le Niveau 1, équivalent à AES-128. StenVault utilise le Niveau 3, équivalent à AES-192, dans une construction hybride avec X25519.
| Algorithme | Niveau NIST | Robustesse équivalente | Statut |
|---|---|---|---|
| ML-KEM-512 / Kyber-512 | Niveau 1 | ≈ AES-128 | Disponible |
| ML-KEM-768 | Niveau 3 | ≈ AES-192 | Utilisé |
| ML-KEM-1024 | Niveau 5 | ≈ AES-256 | Disponible |
StenVault combine ML-KEM-768 avec X25519 dans un véritable KEM hybride. Un attaquant doit briser les deux pour compromettre vos fichiers. Si ML-KEM-768 présente une faiblesse non découverte, X25519 continue de vous protéger. Si X25519 tombe face aux ordinateurs quantiques, ML-KEM-768 continue de vous protéger. Aucun point unique de défaillance cryptographique.
| Primitive | Classique | Post-quantique | Finalité |
|---|---|---|---|
| Encapsulation de clés | X25519 ECDH | ML-KEM-768 (FIPS 203) | Encapsulation de clé par fichier |
| Signatures numériques | Ed25519 | ML-DSA-65 (FIPS 204) | Intégrité des fichiers |
| Authentification par mot de passe | OPAQUE (RFC 9807) | — | Connexion zero-knowledge |
| Chiffrement des fichiers | AES-256-GCM | — | Chiffrement du contenu |
| Dérivation de clés | Argon2id (46 MiB, t=1, p=1) | — | Mot de passe → KEK |
| Format de fichier | CVEF v1.4 (container v2) | — | Enveloppe liée par AAD |
Le livre blanc de sécurité documente les algorithmes, les paramètres, les flux de données et la justification de la conception, avec des citations directes du code source.
Vérifiez dans le code source
Format de fichier CVEF v1.4Chiffrement de fichiers PQC hybrideDépôt de code completComment nous testons
Chaque primitive cryptographique est testée par rapport à des implémentations de référence faisant autorité, pas seulement par des tests unitaires internes.
Chaque primitive cryptographique est testée par rapport aux vecteurs de référence faisant autorité du Project Wycheproof de Google (AES-256-GCM, X25519, Ed25519, HKDF-SHA256, AES Key Wrap), du NIST FIPS 203 et 204 pour ML-KEM-768 et ML-DSA-65, et des RFC 9106 et 3394 pour Argon2id et AES-KW. Les mêmes suites que celles utilisées par OpenSSL et BoringSSL.
Cinq primitives sont testées sur deux bases de code indépendantes qui doivent s'accorder sur chaque résultat : @stenvault/pqc-wasm vs @noble/post-quantum pour ML-KEM-768 et ML-DSA-65, WebCrypto vs @noble/curves pour X25519 et Ed25519, et WebCrypto vs Node.js crypto pour AES-256-GCM.
40 tests basés sur les propriétés génèrent des milliers d'entrées aléatoires par primitive à l'aide de fast-check, vérifiant des invariants universels — les cycles chiffrer-puis-déchiffrer, vérifier-après-signer, l'accord du secret partagé du KEM — sans dépendre de valeurs attendues codées en dur.
Questions
5 Go gratuits, chiffré post-quantique dès le premier jour. Sans carte bancaire.
Sans carte bancaire · 5 Go gratuits pour toujours