Modèle de chiffrement
Format .rkvey v5 : préambule, AEAD par compartiment, commits append-only et isolation des secrets.
Le format .rkvey v5 (Rust Key Vault) implémente un modèle de chiffrement en couches, inspiré des meilleures pratiques HKDF et AEAD. Le schéma mental est simple : mot de passe maître → clé maître → sous-clés → compartiments chiffrés.
Chaque entrée est découpée en compartiments (métadonnées, secrets protégés, manifeste et fichiers joints), chacun avec sa propre clé dérivée via HKDF. Déchiffrer un compartiment ne révèle pas les autres.
Modèle de chiffrement QubKey v5
Mot de passe maître
Entrée utilisateur (UTF-8) — jamais persistée en clair
Argon2id
Salt
16 bytes (préambule)
Memory
64 MB
Iterations
3
Parallelism
4
Output
256 bits
Master Key
256 bits · clé racine du coffre
HKDF-SHA256
info="hdr"
Header Key
header_key
HKDF-SHA256
info="idx"
Index Key
index_key
HKDF-SHA256
info="compartment"
Compartment Key
compartment_key
Pour chaque entrée (v5)
HKDF(master_key, salt=file∥entry_id, info=kind∥sub_id) → Compartment Key
Compartiments chiffrés
Dérivation des clés
La dérivation transforme votre mot de passe maître en clés cryptographiques utilisables. Argon2id est volontairement coûteux en temps et en mémoire (~500 ms, 64 Mo) pour ralentir les tentatives de deviner le mot de passe sur une copie volée du fichier. En v5, chaque compartiment d'entrée reçoit ensuite sa propre clé via HKDF.
Entrée utilisateur → Mot de passe maître (UTF-8)
Argon2id → master_key (256 bits) avec sel aléatoire
HKDF-SHA256 → index_key pour le B-Tree
HKDF-SHA256 → compartment_key par entrée et type de compartiment (métadonnées, secrets, pièce jointe…)
| Paramètre | Valeur | Description | Défaut |
|---|---|---|---|
Variant | Argon2id | Variante hybride recommandée par l'OWASP — résistant aux attaques GPU et side-channel | — |
Memory | 64 MB | Mémoire requise par dérivation — augmente le coût matériel des attaques parallèles | 65536 KB |
Iterations | 3 | Passes sur la mémoire — équilibre sécurité / performance (~500 ms) | — |
Parallelism | 4 | Threads parallèles | — |
Output | 32 bytes | Longueur de la clé dérivée | — |
Salt | 16 bytes | Sel aléatoire stocké dans le préambule | — |
Chiffrement AEAD
AES-256-GCM (par défaut)
- Support hardware AES-NI sur processeurs modernes
- Nonce : 12 bytes, tag d'authentification : 16 bytes
- Limite théorique : ~64 Go de données chiffrées par clé
Quand le choisir : machines avec accélération AES matérielle, usage quotidien standard.
Chiffre par défaut sur la plupart des plateformes pour des performances optimales.
XChaCha20-Poly1305 (optionnel)
- Nonce étendu : 24 bytes (probabilité de collision négligeable)
- Pas de dépendance matérielle — performances constantes sur tous les CPU
- Recommandé pour les clés à longue durée de vie
Quand le choisir : coffres archivés, machines sans AES-NI, préférence pour ChaCha20.
Activable dans les paramètres avancés du coffre.
Structure du fichier
Légende de la structure (v5) :
preamble— magic bytes, version du format, sel Argon2idheader.enc— métadonnées du coffre chiffrées (nom, date de création, paramètres)index/— B-Tree chiffré pour la recherche O(log n) sans déchiffrer les secretscompartments/— blocs AEAD par type : métadonnées, secrets protégés, manifeste, fichiers jointsappend/— région de commits : nouveaux compartiments + snapshot d'index + footer validé
Intégrité et commits
Résilience
Commits append-only garantissent l'intégrité en cas d'interruption :
- Les nouveaux compartiments sont ajoutés en fin de fichier
- Un snapshot d'index chiffré est écrit
- Les données sont synchronisées sur disque (fsync)
- Un footer validé finalise le commit (point de cohérence)
Scénario concret : vous modifiez une entrée et le courant est coupé pendant l'écriture. Au redémarrage, QubKey retrouve le dernier footer valide — aucune donnée perdue, aucune corruption silencieuse. Une compaction périodique compacte le fichier lorsque trop d'espace obsolète s'accumule.
Isolation par compartiment
Grâce à HKDF-SHA256, chaque compartiment reçoit une clé compartment_key unique, dérivée de la clé maître avec l'identifiant d'entrée et le type de compartiment. Conséquences pratiques :
- Afficher une fiche ne déchiffre que les métadonnées ; les secrets restent masqués jusqu'à une révélation explicite
- Les pièces jointes sont chargées une par une (téléchargement / aperçu), pas à l'ouverture du coffre
- L'index B-Tree utilise sa propre clé
index_key, séparée des données - Modifier un secret ne réécrit pas forcément les fichiers joints inchangés
Cette isolation est implémentée nativement dans le format .rkvey v5.
Primitives cryptographiques
| Primitive | Usage | Bibliothèque |
|---|---|---|
| Argon2id | Dérivation mot de passe → clé | argon2 (RustCrypto) |
| HKDF-SHA256 | Dérivation clé → sous-clés | hkdf (RustCrypto) |
| AES-256-GCM | Chiffrement AEAD | aes-gcm (RustCrypto) |
| XChaCha20-Poly1305 | Chiffrement AEAD (alt) | chacha20poly1305 (RustCrypto) |
| HMAC-SHA256 | Intégrité fichier | hmac (RustCrypto) |
| CSPRNG | Génération aléatoire | getrandom (OS) |