khadhroony-solana-project/deltas/0.2.5/pre.001.md

Delta 0.2.5-pre.001 — audit Wallet, threat model, format V1 et sizing

Base requise

Release stable attendue :

v0.2.4

La base fournie confirme workspace.package.version = 0.2.4 avant ouverture.

Type de livraison

ksp-general-0.2.5-pre.001.zip

L'archive d'échange est un delta applicable depuis la racine de v0.2.4 et contient uniquement les fichiers ajoutés/modifiés par cette livraison, conformément à VER-ARCHIVE-004.

Objet

Ouvrir 0.2.5 — Wallet foundation sans commencer par une implémentation cryptographique. Ce delta :

• réaudite les Wallet historiques bot2/bot3 ;
• classe les idées à réutiliser/refondre/abandonner/reporter ;
• formalise le threat model offline du .kspwallet ;
• arrête l'architecture indépendante VIEW/OWNER par content keys + key slots ;
• retient le niveau B pour le read-only VIEW via une autorité Ed25519 de format distincte de la keypair Solana et couvrant tout état mutable/de sécurité ;
• confirme que .kspwallet V1 est entièrement autonome et ne requiert aucun facteur/ancrage externe ;
• rend la keypair Solana V1 immuable après création/import ;
• exige une spec séparée docs/formats/KSPWALLET_V1.md suffisante pour une implémentation indépendante dans un autre langage ;
• choisit l'enveloppe JSON V1 stricte et un transcript binaire sémantique plutôt qu'une signature des octets JSON ;
• réaudite les crates Solana/crypto/persistence actuelles ;
• fixe les candidats V1 sans les ajouter prématurément ;
• distingue rotation de password et révocation cryptographique forte de VIEW ;
• fixe le minimum import/export à Solana CLI JSON + keypair Base58 générique ;
• redimensionne la release de 8 à 10 prereleases avant publication.

Décisions principales

Héritage

Réutiliser conceptuellement : strict 64-byte Solana keypair, signature sans getter secret, redaction/zeroize, spawn_blocking, CSPRNG OS, parsing borné, AEAD/AAD, no-clobber/atomic persistence, Solana CLI JSON, Base58 et inspection sûre.

Refondre : password model, format, alias, unlocked representation, persistence API, logging et adapters.

Abandonner : .kswallet, KSWALLET, alias/pubkey en clair, alias=filename, single password, chiffrement direct du keypair, JSON legacy/migration, WalletPolicy, direct tracing.

Reporter : mnemonic UI, proprietary wallets sans wire normatif prouvé, hardware/remote/recovery.

Threat model

Le fichier volé est attaquable offline sans rate-limit. Les salts sont publics. Aucun pepper KSP n'existe. .kspwallet V1 est explicitement auto-contenu : aucun salt externe, pepper, OTP, service distant, keychain ou ancre externe n'est requis. Les altérations partielles et toute mutation sous l'autorité OWNER originale sont authentifiées ; la substitution/rollback total d'un fichier valide reste indétectable par le seul fichier auto-contenu et cette limite est documentée sans introduire de dépendance externe en V1.

Key hierarchy

VIEW password -> Argon2id VIEW -> KEK VIEW -> wrap K_metadata
OWNER password -> Argon2id OWNER -> KEK OWNER -> wrap K_owner_root

K_owner_root -> owner-control -> K_metadata + K_secret + admin signing secret
K_metadata   -> metadata      -> Pubkey + alias + notes
K_secret     -> secret        -> Solana keypair

OWNER ne dépend jamais de VIEW.

VIEW read-only

Le niveau B est retenu : une clé Ed25519 d'administration du format, distincte de la keypair Solana, signe un transcript déterministe de tout l'état mutable/de sécurité. VIEW peut lire les metadata mais ne peut pas produire sous l'autorité OWNER originale une mutation acceptée de metadata, key slots/passwords, compartments ou keypair. Les modifications physiques d'octets restent possibles pour un attaquant filesystem, mais elles sont rejetées si elles ne portent pas une signature OWNER valide.

Cette garantie ne couvre pas le remplacement complet du fichier et de sa propre clé publique de contrôle par un autre wallet auto-cohérent, ni le rollback intégral vers une ancienne copie valide. V1 n'utilise aucune ancre externe pour masquer cette limite.

Rotation / révocation

rotate_view_password peut rewrap la même K_metadata et invalide l'ancien password pour le fichier courant. Une vraie révocation VIEW génère une nouvelle K_metadata, rechiffre metadata/control et recrée/supprime le slot VIEW.

rotate_owner_password rewrap K_owner_root et ne modifie pas la keypair Solana. La keypair Solana V1 est immuable après création/import ; une autre keypair correspond à un autre wallet, pas à une mutation du wallet existant.

Format V1

JSON UTF-8 strict
magic = KSPWALLET
format_version = 1
Base64url sans padding pour binary wire
key_slots génériques, V1 = OWNER obligatoire + VIEW optionnel
owner_control / metadata / secret séparés
owner_auth_public_key visible, identité Solana cachée
state_signature Ed25519 couvrant tout état mutable/de sécurité
unknown fields/version = reject
pas de checksum séparé
aucune dépendance externe requise pour ouvrir/vérifier V1

La signature porte sur un transcript binaire déterministe et domain-separated, pas sur une canonicalisation JSON.

Crypto candidate

KDF        Argon2id v19
AEAD       XChaCha20-Poly1305
CSPRNG     getrandom / OS
memory     zeroize
admin auth Ed25519 standard, dépendance directe à confirmer par cargo tree

Les paramètres Argon2 de création ne sont pas figés ici. Ils seront benchmarkés avant freeze et sérialisés par slot ; le parseur aura des caps anti-DoS avant KDF.

Import/export minimum

solana-cli-json
solana-keypair-base58

Pas de nom/adapteur Phantom/Solflare/Backpack/Trust sans wire actuel suffisamment normatif.

Prévision révisée

pre.001  audit + threat model + design + sizing
pre.002  crate/API foundation + errors/logging/canaries
pre.003  strict JSON wire + key slots + transcript/AAD + contrat docs/formats + spec initiale
pre.004  KDF benchmark + AEAD/wrapping + vectors crypto in-memory
pre.005  compartments + create/open VIEW/OWNER + state signature
pre.006  persistence atomic/no-clobber + async + filesystem hardening
pre.007  signing + metadata admin + rotations + VIEW strong revoke/recreate
pre.008  extensible import/export + CLI JSON + Base58 + inspect
pre.009  security/interoperability/compliance audit + adversarial tests + cargo trees
pre.010  spec/README/USAGE/graphes/prompt Wallet Desk + candidate close
rel.001  publication stricte

Le plan détaillé est docs/plans/012-V0_2_5_WALLET_FOUNDATION_PLAN.md.

Correction de l'artefact d'échange avant validation

Une première archive préparatoire avait été produite à tort comme copie complète du dépôt. Elle est invalidée explicitement et ne doit pas être appliquée : elle ne respectait pas VER-ARCHIVE-001/VER-ARCHIVE-004. Comme cette livraison n'a pas été validée ni indiquée comme commitée par l'opérateur, le présent artefact est la livraison pre.001 correcte, reconstruite comme delta depuis v0.2.4; il ne s'agit pas d'un fix fonctionnel appliqué après commit.

La même revue a durci deux points de conception avant implémentation : autonomie absolue du format V1 et authentification OWNER de tout état mutable, avec la limite irréductible du remplacement total clairement séparée.

Fichiers ajoutés

docs/plans/012-V0_2_5_WALLET_FOUNDATION_PLAN.md
deltas/0.2.5/pre.001.md

Fichiers modifiés

Cargo.toml
ROADMAP.md
docs/000-README.md
docs/plans/000-README.md
docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md

Fichiers volontairement inchangés

CHANGELOG.md
crates/**
config/**
docs/validation/**
deltas/0.2.4/**

Aucune crate Wallet ni dépendance crypto n'est ajoutée par le gate. Le changelog reste synchronisé en fin de session conformément à VER-SESSION-005.

Audit de dépendances actuel

Constats externes au 2026-08-18, sans modification Cargo dans ce delta :

solana-pubkey       4.3.0
solana-keypair      3.1.2
solana-signer       3.0.1
argon2              0.5.3
scrypt              0.12.0
pbkdf2              0.13.0
chacha20poly1305    0.11.0
aes-gcm-siv         0.12.0
getrandom           0.4.3
zeroize             1.9.0
ed25519-dalek       3.0.0
base64              0.23.1
tempfile            3.27.0

Les versions directes Solana/crypto seront réauditées au moment exact où chaque dépendance est introduite. solana-signature 3.5.2 est la publication courante auditée ; son ajout direct reste conditionné à la surface publique réellement retenue et au cargo tree de ce moment.

Validations exécutées

• inspection/réaduit de l'archive stable KSP v0.2.4 fournie ;
• relecture de l'index RULES.md, de l'ensemble des fichiers docs/rules/*.md, des documents architecture/plans/validation Wallet demandés et des conventions de delta/archive ;
• confirmation des frontières Wallet déjà documentées et de VER-ARCHIVE-004 ;
• inspection globale de l'archive historique bot3 et lecture détaillée de ks-wallet, de ses tests, guides, plan/validation Wallet, format natif et héritage bot2 Wallet ;
• inspection de l'ancien TemporaryWalletStore bot2 ;
• réaudit des primitives/crates publiées actuelles nécessaires au plan ;
• confirmation que le gate ne nécessite aucune nouvelle dépendance dans pre.001 ;
• vérification documentaire que le nouveau plan ne réintroduit ni Config, Transport, Store, Tauri ni WalletPolicy dans Wallet ;
• contrôle que V1 ne requiert aucun facteur externe et que la spec multi-langages séparée est un critère de clôture ;
• contrôle du contenu de l'archive d'échange selon VER-ARCHIVE-004 : sept chemins seulement, tous ajoutés/modifiés par pre.001.

Validations non exécutées

Le sandbox courant ne fournit pas le binaire cargo; les validations Cargo doivent être rejouées par l'opérateur avant commit :

cargo fmt --all
cargo check --workspace
cargo clippy --workspace --all-targets

cargo test -p ksp-wallet-lib n'est pas applicable à pre.001 puisque la crate n'existe volontairement pas encore.

Aucun cargo tree ne peut être pertinent à ce stade puisque les dépendances ne changent pas. Il devient obligatoire dès leur introduction et à la compliance finale.

L'archive stable fournie ne contient pas .git; le commit attendu après application et validations suit :

v0.2.5-pre.001

Questions bloquantes

Aucune pour pre.002.

Les paramètres Argon2 de production sont volontairement non décidés avant benchmark ; ce n'est pas une question d'architecture bloquante.

Suite

0.2.5-pre.002 : créer crates/ksp-wallet-lib avec foundation API/capabilities, erreurs, logging KSP et canaries de frontières, sans encore implémenter le chiffrement .kspwallet.