4.5 KiB
Delta 0.2.4-pre.009-fix.001 — enrichissement du prompt 0.2.5 Wallet
Type
Fix documentation-only.
Aucun changement Rust, Cargo, runtime, test, fixture HTTP ou contrat 0.2.4 n'est introduit.
Le workspace.package.version reste :
0.2.4-pre.9
Le delta historique :
deltas/0.2.4/pre.009.md
reste inchangé.
Motif
Après validation de la candidate 0.2.4-pre.009, le brainstorming préparatoire à 0.2.5 — Wallet foundation a précisé des exigences importantes qui doivent être présentes dans le prompt de reprise avant l'ouverture de la nouvelle release.
Le prompt précédent couvrait déjà :
audit crypto actuel
KDF / AEAD / CSPRNG
format versionné
persistence atomique
secret memory handling
signature
import/export
mais ne formalisait pas encore suffisamment :
interopérabilité externe obligatoire du .kspwallet
threat model de bruteforce offline
absence de secret KSP/pepper propriétaire nécessaire à la récupération
Pubkey/alias/notes invisibles wallet verrouillé
alias interne indépendant du filename
notes protégées
sémantique exacte du format_version
paramètres KDF sérialisés
distinction éventuelle format_version / payload_version
deux capacités indépendantes VIEW / OWNER
architecture key slots / key wrapping
rotation indépendante des passwords sans changement de keypair
OWNER capable de recréer VIEW sans ancien password VIEW
question du read-only cryptographique de VIEW
test vectors publics pour implémentations externes
Prompt mis à jour
prompts/010-V0_2_5_START_PROMPT.md passe :
version 1 -> version 2
Interopérabilité
Le .kspwallet doit être complètement spécifiable en dehors de ksp-wallet-lib.
La sécurité ne doit pas dépendre :
du secret du format
d'un pepper global KSP
d'une donnée cachée dans le binaire
Une future spécification KSPWALLET_V1 et des vecteurs de test publics doivent permettre l'écriture d'un déchiffreur compatible externe.
Threat model
Le prompt impose désormais l'audit explicite de l'attaque offline :
copie du fichier
-> essais de passwords sans serveur/rate-limit
-> KDF coûteux mais password faible toujours attaquable
et sépare les garanties apportées par :
crypto du fichier
capabilities/types KSP
filesystem
éventuelle ancre de confiance externe
Metadata protégée
Sans VIEW ou OWNER, le fichier ne doit pas exposer par défaut :
Pubkey
alias
notes
L'alias reste indépendant du filename.
Les notes sont des metadata protégées, lisibles par VIEW/OWNER et administrables par OWNER.
Versionnement
format_version est explicitement défini comme une version du format, non comme un compteur d'éditions.
Il ne change pas pour :
rotation password
modification alias
modification notes
réécriture atomique sans changement de format
Un éventuel payload_version doit être séparé uniquement si le schéma protégé nécessite réellement une évolution indépendante.
Capacités VIEW / OWNER
Le modèle cible devient :
VIEW:
lire Pubkey/alias/notes
OWNER:
tout VIEW
signer
modifier alias/notes
gérer VIEW
changer OWNER
Invariants :
VIEW et OWNER indépendants
OWNER ne dépend jamais de VIEW
VIEW compromis != secret Solana compromis
VIEW compromis != OWNER compromis
OWNER peut recréer/supprimer VIEW sans ancien VIEW password
rotation VIEW/OWNER != changement de keypair
Le prompt demande d'étudier une architecture de :
content keys
key wrapping
key slots indépendants
plutôt qu'un double chiffrement naïf.
Read-only de VIEW
L'API KSP doit obligatoirement rendre VIEW read-only.
Le gate pre.001 doit aussi décider si V1 renforce cette propriété cryptographiquement contre un détenteur VIEW malveillant.
La préférence est de viser cette propriété si elle reste propre, interopérable et raisonnablement simple, avec une autorité metadata OWNER distincte de la keypair Solana sauf justification contraire.
Le prompt conserve explicitement la limite suivante :
aucune information de confiance stockée uniquement dans le fichier
ne peut empêcher un attaquant ayant accès en écriture
de remplacer entièrement ce fichier par un autre fichier valide
Fichiers
Modifié :
prompts/010-V0_2_5_START_PROMPT.md
Ajouté :
deltas/0.2.4/pre.009-fix.001.md
Aucun autre fichier n'est modifié.