anchorage_layer_simple/userwallet/features/userwallet-dh-systematique-scan-fetch.md

UserWallet – DH systématique et flux scan → fetch par hash → déchiffrer

Author: Équipe 4NK
Date: 2026-01-26

Question

Le DH est-il systématiquement mis en place pour les types de messages envoyés (sauf DH) afin que l’utilisateur scanne → aille chercher le hash avec le message → qu’il sache alors déchiffrer ?

Réponse courte

Non. Aujourd’hui le DH n’est pas systématique pour tous les types de messages. Seul le pairing utilise ECDH + MsgCle lorsque la clé publique du pair distant est connue ; le login et le sync générique ne suivent pas ce schéma.

---

État actuel par type de message

1. Pairing (membre finaliser)

• Envoi : si PairConfig.publicKey (pair distant) est défini → chiffrement ECDH, POST MsgChiffre + POST MsgCle (df_ecdh_scannable = clé publique de l’émetteur). Sinon → message en clair (base64), aucun MsgCle.
• Réception : fetchPairingMessage (hors sync générique) fetch messages → fetch keys par hash → déchiffrement ECDH si senderPublicKey / identité connus, sinon base64.
• DH systématique ? Non. DH seulement si clé publique du pair connue ; sinon pas de DH, pas de MsgCle.

2. Login (challenge)

• Envoi : encryptForAll (clé symétrique aléatoire), POST MsgChiffre + POST signatures. Aucun POST MsgCle.
• Réception : la preuve est envoyée au parent (iframe) via postMessage. Le message login sur le relais n’est pas déchiffré par le sync (pas de MsgCle, donc fetchKeys vide → indechiffrable).
• DH systématique ? Non. Pas de DH, pas de MsgCle. Pas de flux « scan → fetch par hash → déchiffrer » pour le login.

3. Sync générique (Service, Contrat, Champ, Action, Membre, Pair…)

• Réception : tryDecrypt fait fetchKeys(hash) puis, si keys.length > 0, atob(message_chiffre) (base64) uniquement. Les clés et le df_ecdh_scannable ne sont pas utilisés pour du vrai déchiffrement ECDH.
• Flux : on fetch les messages (par plage / service), puis les clés par hash. Pas de « scan des MsgCle en premier → hashes déchiffrables via ECDH → fetch messages par hash » comme dans les specs.
• DH systématique ? Non. Le sync suppose du base64 et n’applique pas un schéma DH systématique.

---

Ce que prévoient les specs

• Message individuel de déchiffrement : hash + clé de chiffrement + df = « diffie-hellman à scanner » pour obtenir la clé de déchiffrement (secret partagé).
• Flux : « Récupérer et scanner tous les messages de clés » (depuis date anniversaire / checkpoint) ; les messages déchiffrables sont identifiés via les DH ; puis on va chercher le message par hash et on déchiffre.
• Publish to all : tout est chiffré ; seuls les pairs qui peuvent dériver la clé (via ECDH) peuvent lire. Le « matériel DH » est publiable car inexploitable par les tiers.

Donc, pour les types de messages hors DH : chiffrement + MsgCle avec df_ecdh_scannable systématique, et flux scan des clés → fetch message par hash → déchiffrer.

---

Écarts principaux

Aspect	Specs	Actuel
DH pour tous les messages (hors DH)	Oui, via MsgCle + df	Non : login sans MsgCle ; pairing optionnel ; sync en base64
Flux	Scan MsgCle → hashes déchiffrables → fetch message par hash	Fetch messages → fetch keys par hash ; pas de scan MsgCle centré ECDH
Utilisation des clés en sync	Déchiffrement ECDH avec df	Base64 si keys.length > 0 ; clés non utilisées
Login	Sous-entendu publish to all + MsgCle/DH si d’autres doivent déchiffrer	encryptForAll seul, pas de MsgCle

---

Pistes pour alignement

1. Login : si le message login sur le relais doit être déchiffrable (ex. par le service ou un autre client) → publier des MsgCle avec df_ecdh_scannable pour les destinataires concernés (p.ex. clé publique du service ou des pairs), au lieu de se limiter à encryptForAll sans MsgCle.
2. Pairing : rendre DH obligatoire dès qu’un pair distant existe (exiger publicKey), et ne plus envoyer de membre finaliser en clair (base64).
3. Sync :
   • Implémenter un scan des MsgCle (depuis anniversaire / checkpoint), identification des hash déchiffrables via ECDH (quand on a la clé privée correspondante).
   • Ensuite fetch des messages par hash pour ces hash uniquement.
   • Remplacer le « base64 si keys > 0 » par un vrai déchiffrement ECDH utilisant df_ecdh_scannable et les clés.
4. Types contrats / graphe (service, contrat, champ, action, membre, pair) : définir quels types sont publiés par qui, avec quels MsgCle / DH, et appliquer le même flux scan → fetch par hash → déchiffrer pour tous.

---

Références

• userwallet/docs/specs.md : Message individuel de déchiffrement, df DH à scanner, « récupérer et scanner tous les messages de clés », fenêtre de scan, fetch par hash.
• userwallet/features/userwallet-pairing-connecte.md : chiffrement pairing ECDH vs base64, MsgCle.
• userwallet/src/utils/encryption.ts : encryptWithECDH / decryptWithECDH, encryptForAll / decryptForAll.
• userwallet/src/services/pairingConfirm.ts : publication pairing + MsgCle, fetchPairingMessage, ECDH.
• userwallet/src/services/syncService.ts : tryDecrypt (base64), fetchKeys.
• userwallet/src/services/loginBuilder.ts : encryptForAll, pas de MsgCle.