Files
khadhroony-bot3/ks-wallet/README.md

6.0 KiB
Raw Blame History

ks-wallet

ks-wallet fournit la frontière wallet Solana générale du workspace Khadhroony.

État actuel

En 0.5.2-pre.005, la crate sait en plus migrer sans destruction un legacy Solana JSON, importer/exporter le format Solana CLI JSON et transférer un keypair complet via le format privé Base58 utilisé comme adaptateur tiers de référence pour Phantom. La dérivation Argon2id et le chiffrement authentifié XChaCha20-Poly1305 restent la protection du conteneur natif .kswallet.

La crate fournit actuellement :

  • alias validés ;
  • identité publique minimale WalletIdentity sans chemin local ;
  • WalletManager pour scanner/lookup les .kswallet structurellement valides du répertoire configuré ;
  • inspection explicite d'un .kswallet sélectionné hors du store via un handle opaque ;
  • décodage et encodage v1 stricts avec identité publique déclarée, paramètres KDF/AEAD bornés et payload keypair de taille exacte ;
  • création persistante native avec WalletManager::create() et publication atomique/no-clobber ;
  • ouverture authentifiée par alias avec WalletManager::unlock() ;
  • ouverture d'un fichier explicitement sélectionné avec WalletManager::unlock_file() sans l'enregistrer dans le store ;
  • changement du mot de passe avec WalletManager::change_password() en conservant exactement la même keypair/pubkey ;
  • migration non destructive de <alias>.json vers <alias>.kswallet avec WalletManager::migrate_legacy() ;
  • inspection sûre d'un fichier de transfert via inspect_transfer_file(), qui valide le keypair sans l'importer et ne retourne que sa pubkey publique ;
  • inventaire stable des formats via WalletTransferFormat::supported() avec code, libellé et extension conventionnelle ;
  • import de fichiers secrets avec WalletManager::import_file() en SolanaCliJson ou SolanaPrivateKeyBase58 ;
  • export de fichiers secrets avec WalletManager::export_file(), uniquement après authentification du mot de passe du .kswallet ;
  • refus des collisions dalias et de pubkey lors dun import ;
  • publication dexport privée, atomique et sans écrasement silencieux ;
  • WalletPassword, frontière possédée, non clonable et redacted pour une opération ;
  • UnlockedWallet, capacité de signature authentifiée non clonable et sans getter des bytes privés ;
  • wallet temporaire en mémoire ;
  • stockage legacy local JSON d'un keypair Solana ;
  • création exclusive avec refus d'écrasement et reprise des courses load_or_create ;
  • résumé/identité sans matériau cryptographique secret ni chemin local ;
  • accès au trait Signer sans exposition des octets ;
  • signature de messages ;
  • permissions Unix privées et contrôles de fichiers ;
  • effacement des buffers secrets temporaires utilisés lors de la lecture ou écriture.

La persistance legacy écrit encore directement le contenu dans le chemin final : elle n'est pas une publication atomique crash-safe par fichier temporaire + renommage.

Cible 0.5.2

ks-wallet doit devenir capable de :

  • découvrir dans le store les fichiers <alias>.kswallet valides et gérer plusieurs wallets persistants accessibles par alias ;
  • conserver des wallets temporaires/jetables pour tests et scénarios ;
  • stocker les wallets persistants dans un format natif binaire <alias>.kswallet ;
  • protéger chaque wallet persistant par un mot de passe modifiable ;
  • fournir une capacité de signature sans exposer les bytes privés ;
  • importer le format legacy et d'autres formats explicitement supportés ;
  • exporter volontairement vers des formats externes supportés ;
  • exiger un mot de passe valide pour tout export contenant le secret ;
  • préserver exactement la même keypair lors d'un changement de mot de passe ;
  • importer et exporter obligatoirement le format keypair JSON des binaires Solana ;
  • documenter les formats compatibles des principaux wallets Solana, implémenter un adaptateur tiers d'exemple et reporter les autres au TODO.

Le format .kswallet est propre à ks-wallet, mais sa protection cryptographique utilise des primitives établies : Argon2id v19 pour la dérivation depuis le mot de passe et XChaCha20-Poly1305 pour le chiffrement authentifié. Le layout normatif est documenté dans ../docs/NATIVE_FORMAT.md. Le payload secret v1 est exactement la keypair Solana brute de 64 octets ; avec le tag AEAD, le ciphertext est fixé à 80 octets. Le header, l'alias, le sel et le nonce sont authentifiés comme AAD avant qu'une capacité UnlockedWallet puisse être produite. Changer le mot de passe ne change jamais la keypair : une modification réelle du secret Ed25519 produirait une autre pubkey et donc un autre wallet. Le changement du mot de passe reprotège le fichier persistant ; il ne révoque pas une capacité UnlockedWallet déjà détenue par un consommateur, qui doit être explicitement lock()/dropée selon son propre cycle de vie.

Le scan automatique reste strictement borné au répertoire fourni à WalletManager. Un programme peut néanmoins demander l'inspection d'un autre fichier .kswallet choisi explicitement, par exemple via un file browser desktop, puis l'ouvrir avec unlock_file() et le mot de passe fourni. Ces opérations ne modifient pas le store et ne rendent pas le chemin public.

Relations

ks-wallet possède et gère le wallet. Les exécuteurs et ks-lib doivent dépendre d'une capacité de signature, pas du format de stockage ni des octets privés.

ks-config peut sélectionner un alias ou une identité non sensible, mais ne stocke aucun mot de passe ni matériau secret.

Une application desktop doit projeter les informations autorisées dans ses propres DTO Tauri ; ks-wallet ne réintroduit pas TS-RS.

Documentation