Cryptographie
La cryptographie vit dans @vaultkeepr/core, publié sur npm sous licence MIT. Les primitives proviennent de @noble/ciphers, @noble/curves et @noble/hashes ; le paquet n’implémente pas ses propres maths de chiffrement.
Dérivation de clé
Section intitulée « Dérivation de clé »L’application dérive la clé de chiffrement du coffre à partir de votre mot de passe maître avec Argon2id, avec ces paramètres :
| Paramètre | Valeur |
|---|---|
| Coût temps (t) | 3 |
| Coût mémoire (m) | 64 MiB |
| Parallélisme (p) | 4 |
Ces valeurs sont vérifiées par les tests du paquet : une dérive des paramètres fait échouer la CI au lieu de partir en production silencieusement. Le mot de passe maître n’est jamais transmis ni stocké ; il existe dans votre mémoire et brièvement dans la mémoire de l’appareil pendant la dérivation. Un sel aléatoire est généré par coffre (generateSaltArgon2).
Chiffrement
Section intitulée « Chiffrement »Le contenu du coffre est chiffré avec XChaCha20-Poly1305, un AEAD, avec des nonces aléatoires. Ce qui quitte l’appareil pour la sync, la sauvegarde ou l’épinglage, c’est du chiffré. L’intégrité du coffre est garantie par un engagement HMAC-SHA256 : la modification d’un blob de coffre fait échouer le déchiffrement au lieu de renvoyer des données altérées.
encryptVault et decryptVault effacent la clé maître après usage par défaut (wipeKeyAfterUse). Le déchiffrement exige de re-dériver la clé depuis votre mot de passe à chaque fois.
Enveloppes ECIES
Section intitulée « Enveloppes ECIES »Certains secrets voyagent entre parties, par exemple une clé maître scellée pour un bénéficiaire d’héritage. Le cœur utilise ECIES avec des clés secp256k1 pour ces enveloppes : l’expéditeur chiffre vers la clé publique du destinataire, et seule la clé privée du destinataire peut les ouvrir. Les signatures de session et de délégation suivent les schémas EIP-4361, implémentés dans @vaultkeepr/wallet-messages.
Autres surfaces du cœur
Section intitulée « Autres surfaces du cœur »- TOTP :
getTOTPCodeetparseTOTPUripour les codes à deux facteurs - Crypto passkey, NFC et MRZ
- Génération de mots de passe, contrôles de santé et estimation d’entropie
- Listes de mots BIP-39 et EFF
- Import et export pour plus de 10 formats de gestionnaires (Bitwarden, 1Password, LastPass, Keeper, Dashlane, Enpass, KeePass XML, RoboForm, Proton Pass, etc.)
- Fusion à trois voies et utilitaires d’appairage
La suite de tests du paquet couvre la résistance à la falsification et la séparation des clés v2/v3, entre autres (510 tests dans le dépôt au moment de l’évaluation de sécurité).
Pourquoi ces primitives
Section intitulée « Pourquoi ces primitives »Le projet n’écrit pas son propre code de chiffrement. Chiffrements, courbes et hachages proviennent des bibliothèques @noble/*, et viem fournit les types et clients Ethereum. Les lockfiles épinglent les versions et la CI installe en mode frozen, donc un changement de dépendance est une modification relue, pas un changement silencieux. L’évaluation de sécurité liste la compromission supply-chain de @noble/* ou viem comme risque suivi et documente ses atténuations : installations frozen, actions CI épinglées par SHA, secret scanning avec push protection et mises à jour Dependabot hebdomadaires.
Fichiers sources
Section intitulée « Fichiers sources »- packages/core/README.md — exemples d’usage et notes de sécurité
- docs/THREAT_MODEL.md — tableau des biens protégés avec les paramètres Argon2id
- SECURITY_ASSESSMENT.md — ligne de risque cryptographique et nombre de tests