
Gestionnaire de mots de passe chiffré local d'abord pour les identifiants, les notes et les clés API, utilisant un coffre-fort SQLite scellé avec Argon2id et XChaCha20-Poly1305 ; sans cloud ni télémétrie.
GTK4 / gtkmm-4 · C++23 · CMake · SQLite · libsodium
lsPass stocke identifiants, notes sécurisées et clés API dans un coffre local chiffré. Pas de réseau, pas de cloud, pas de télémétrie. Rien de secret n'est jamais écrit en clair sur le disque.
sudo apt install libgtkmm-4.0-dev libsqlite3-dev libsodium-dev nlohmann-json3-dev
cmake -B build
cmake --build build -j
ctest --test-dir build --output-on-failure # 41 unit tests
./build/lspass
Le coffre se trouve dans ~/.local/share/lspass/vault.db (permissions 0600).
cmake -B build-rel -DCMAKE_BUILD_TYPE=Release
cmake --build build-rel -j
cd build-rel && cpack -G DEB # requires: dpkg-dev, file
sudo dpkg -i ../packages/deb/lspass_1.0.0_amd64.deb
Le .deb est produit dans packages/deb/ et fournit le binaire, une
entrée de lanceur com.lspass.App.desktop et l'icône de l'application
(packaging/com.lspass.App.svg, installée dans le thème hicolor).
cmake --install sans CPack utilise le préfixe /usr/local par défaut. Les dépendances
d'exécution (libgtkmm-4.0, libsodium, libsqlite3, …) sont résolues automatiquement par
dpkg-shlibdeps, donc apt --fix-broken install ou sudo apt install ./lspass_1.0.0_amd64.deb installe tout ce qui est nécessaire.
Basé sur l'OWASP Password Storage Cheat Sheet, la documentation de libsodium et le modèle de chiffrement en enveloppe utilisé par les gestionnaires de mots de passe établis (Bitwarden, enveloppement de clé de type KeePassXC) :
master password
│ Argon2id (memory-hard KDF, random 128-bit salt,
▼ opslimit/memlimit = libsodium "moderate",
KEK (32 B) parameters stored in vault for future upgrades)
│ XChaCha20-Poly1305 (key wrap)
▼
DEK (32 B, random) ── wraps nothing else, RAM only, never on disk
│ XChaCha20-Poly1305 AEAD per field
▼
SQLite: entries(title, username, url [plaintext metadata],
secret, notes [sealed blobs: nonce‖ct‖poly1305 tag])
Pourquoi ces choix :
Compromis assumé : title, username et url sont stockés en clair
afin que la liste/la recherche fonctionne sans déchiffrer chaque ligne. Les
secrets eux-mêmes (mots de passe, notes, clés API) sont toujours des blobs scellés.
Le test unitaire secrets_not_stored_in_plaintext analyse octet par octet le fichier
du coffre (y compris le WAL) pour y chercher un secret factice et prouver cela.
ctest exécute trois suites (41 cas) contre la bibliothèque principale
indépendante de l'interface graphique. L'ensemble de la suite est également exécuté
sous AddressSanitizer + UBSan :
cmake -B build-san -DCMAKE_CXX_FLAGS="-fsanitize=address,undefined" \
-DCMAKE_EXE_LINKER_FLAGS="-fsanitize=address,undefined"
cmake --build build-san -j && ctest --test-dir build-san
Les compilations release ajoutent -fstack-protector-strong, -D_FORTIFY_SOURCE=2,
PIE et RELRO complet (-Wl,-z,relro,-z,now).
src/core/crypto.{hpp,cpp} SecureBytes, Argon2id KDF, XChaCha20-Poly1305, key wrap
src/core/vault.{hpp,cpp} SQLite vault, envelope encryption, CRUD
src/core/generator.{hpp,cpp} CSPRNG password/passphrase generator
src/ui/ gtkmm-4 UI (unlock screen, list, editor dialogs)
tests/ ctest suites (no external framework needed)
MIT — voir LICENSE.
| Décision | Justification |
|---|
| KDF Argon2id | Premier choix d'OWASP pour les clés dérivées d'un mot de passe ; gourmand en mémoire, résistant au craquage par GPU/ASIC. Les paramètres dépassent le minimum OWASP (m ≥ 19 MiB, t = 2). |
| Chiffrement en enveloppe (DEK aléatoire enveloppée par la KEK) | Changer le mot de passe principal ne fait que ré-envelopper 32 octets au lieu de ré-chiffrer tout le coffre ; la compromission de la DEK est impossible sans la KEK. |
| XChaCha20-Poly1305 AEAD | Des nonces aléatoires de 192 bits rendent la réutilisation de nonce sans objet ; Poly1305 authentifie chaque texte chiffré, donc un mauvais mot de passe principal est détecté par un échec d'authentification — aucun hash ni vérificateur de mot de passe n'est stocké nulle part. |
Liaison AAD (lspass:v1:entry:<id>:<field>) | Un attaquant disposant d'un accès en écriture au fichier de base de données ne peut pas transplanter des textes chiffrés entre entrées ou champs. |
| Nouveau nonce à chaque écriture | Chaque enregistrement re-scelle avec un nouveau nonce aléatoire. |
| Hygiène mémoire | Les clés vivent dans SecureBytes, effacées avec sodium_memzero à la destruction ; l'interface efface les champs de mot de passe immédiatement après utilisation ; le presse-papiers s'efface automatiquement 30 s après la copie (et uniquement s'il contient encore notre secret). |
| Permissions des fichiers | Le fichier du coffre est chmod 0600. |
| Générateur de mots de passe | CSPRNG du noyau avec échantillonnage par rejet (pas de biais modulo), garantit toutes les classes de caractères activées, exclut par défaut les glyphes ambigus ; ~128 bits d'entropie pour les 20 caractères par défaut. |