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 (avant implémentation)

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 après implémentation (DH systématique + flux scan → fetch → déchiffrer)

1. Pairing (membre finaliser)

• Envoi : DH obligatoire. recipientPublicKey (clé du pair distant) et senderIdentity requis. Chiffrement ECDH, POST MsgChiffre + POST MsgCle (df_ecdh_scannable = clé publique de l’émetteur). Plus de base64.
• Réception : fetchPairingMessage → fetch messages → fetch keys par hash → déchiffrement ECDH uniquement (plus de base64). Si pas de senderPublicKey / identité → message ignoré.
• UX : formulaire pairing avec saisie « Clé publique (hex, 66 car.) » du pair distant ; affichage de la clé publique locale pour copie sur l’autre appareil.

2. Login (challenge)

• Envoi : ECDH vers l’identité (destinataire = nous). POST MsgChiffre + POST MsgCle (df_ecdh_scannable = clé publique émetteur) + POST signatures. Plus de encryptForAll ni clé symétrique.
• Réception : preuve envoyée au parent (iframe). Message login sur le relais déchiffrable via sync (scan keys → fetch par hash → ECDH).

3. Sync générique

• Flux : scan des MsgCle (GET /keys?start=&end=) → regroupement par hash_message → fetch message par hash (GET /messages/:hash) → déchiffrement ECDH (tryDecryptWithKeys avec df_ecdh_scannable + identité). Plus de base64.
• Identité : SyncService reçoit LocalIdentity | null ; sans identité, messages traités comme indéchiffrables.

---

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 (avant implémentation)

Aspect	Specs	Actuel (avant)
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	encryptForAll seul, pas de MsgCle

Implémentation réalisée

1. api-relay : GET /keys?start=&end= (fenêtre received_at), StorageService.getKeysInWindow.
2. userwallet relay : getKeysInWindow, getMessageByHash.
3. Login : LoginBuilder utilise encryptWithECDH (identité comme destinataire), challengeToMsgCle, loginPublish POST MsgCle en plus de MsgChiffre et signatures.
4. Pairing : DH obligatoire ; publishPairingMessage exige recipientPublicKey et senderIdentity ; plus de base64. fetchPairingMessage ECDH uniquement. UX : saisie clé publique (hex 66 car.) + affichage clé locale.
5. Sync : flux scan-first. SyncService(relays, graphResolver, identity). Pour chaque relais : getKeysInWindow → regroupement par hash → getMessageByHash → tryDecryptWithKeys (ECDH) → validation → mise à jour graphe. syncDecrypt.tryDecryptWithKeys utilise decryptWithECDH avec df_ecdh_scannable.

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.
• userwallet/src/services/pairingConfirm.ts : publication pairing + MsgCle (DH obligatoire), fetchPairingMessage (ECDH seul).
• userwallet/src/services/syncService.ts : flux scan-first, getKeysInWindow → getMessageByHash → tryDecryptWithKeys.
• userwallet/src/services/syncDecrypt.ts : tryDecryptWithKeys (ECDH).
• userwallet/src/services/loginBuilder.ts : ECDH + challengeToMsgCle.