5de870fa13
**Motivations:** - Continue implementation of login state machine - Add new login components for collect, share and sign screens - Add utilities for login signing, validation, and publishing - Update documentation for CNIL compliance and login workflow - Add features for timeouts, backoff, and validator acceptance **Root causes:** - N/A (feature additions and improvements) **Correctifs:** - Update login state machine implementation - Update graph resolver and sync service **Evolutions:** - Add LoginCollectShare and LoginSignScreen components - Add useSignAndPostLogin hook - Add login utilities: loginSign, loginPublish, loginValidation, collectSignatures - Add sync utilities: syncUpdateGraph, syncValidate - Add validatorsAccept utility - Update App.tsx and LoginScreen.tsx - Update loginBuilder and loginStateMachine services - Add documentation for CNIL compliance, remote collection, timeouts, and validator acceptance - Update identity types **Pages affectées:** - userwallet/src/App.tsx - userwallet/src/components/LoginScreen.tsx - userwallet/src/components/LoginCollectShare.tsx (new) - userwallet/src/components/LoginSignScreen.tsx (new) - userwallet/src/hooks/useSignAndPostLogin.ts (new) - userwallet/src/services/graphResolver.ts - userwallet/src/services/loginBuilder.ts - userwallet/src/services/loginStateMachine.ts - userwallet/src/services/syncService.ts - userwallet/src/services/syncUpdateGraph.ts (new) - userwallet/src/services/syncValidate.ts (new) - userwallet/src/types/identity.ts - userwallet/src/utils/relay.ts - userwallet/src/utils/collectSignatures.ts (new) - userwallet/src/utils/loginPublish.ts (new) - userwallet/src/utils/loginSign.ts (new) - userwallet/src/utils/loginValidation.ts (new) - userwallet/src/utils/validatorsAccept.ts (new) - userwallet/docs/synthese.md - userwallet/docs/specs-champs-obligatoires-cnil.md - userwallet/features/userwallet-acceptation-version-validateurs.md (new) - userwallet/features/userwallet-dh-systematique-scan-fetch.md (new) - features/userwallet-contrat-login-reste-a-faire.md - features/userwallet-login-state-machine.md - features/userwallet-validation-conformite.md - features/userwallet-champs-obligatoires-cnil.md (new) - features/userwallet-collecte-distante-2-devices.md (new) - features/userwallet-timeouts-backoff.md (new) - mempool (submodule) - hash_list.txt - hash_list_cache.txt
79 lines
5.4 KiB
Markdown
79 lines
5.4 KiB
Markdown
# 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.
|