Doc_references.md added

doc/Auth-Specs.md

@@ -30,23 +30,7 @@ Ce système couvrira la conception et le développement de l'architecture d'auth
 
 ## 3. <a name='Documentsderfrence'></a>3. Documents de référence
 
-### 3.1. <a name='Worfklows'></a>Worfklows
+Voir [Doc_references.md](Doc_references.md).
-
-* **Items**: Item-Specs.md
-* **PRD et PCD**: PRD-PCD-Specs.md
-* **Messages et transactions SP**: Message-SP-Specs.md
-* **Process et roles**: Process-Role-Specs.md
-
-### 3.2. <a name='Transverse'></a>Transverse
-
-* **Définitions et abréviations.**: Specs-Definition.md
-* **Exigences de sécurité**: Specs-Security.md
-* **Code**: Specs-Code.md
-* **Maintenance, environnement de déploiement**: Specs-Deployment.md
-* **References**: Specs-References.md
-
-* **Diagramme d'architecture montrant les composants principaux du système de login.**
-[SheatSheet 4NK](https://cryptpad.fr/diagram/#/2/diagram/view/3UG+7ccutUvJlwJ1-bR40RhgOA+rb5eEmw42wtkN19A)
 
 ## 4. <a name='Authentificationdesutilisateurs'></a>Authentification des utilisateurs
 

doc/Doc_references.md

@@ -0,0 +1,32 @@
+<!-- vscode-markdown-toc -->
+* 1. [Worfklows](#Worfklows)
+* 2. [Transverse](#Transverse)
+* 3. [3.3. Diagrammes d'architecture](#Diagrammesdarchitecture)
+
+<!-- vscode-markdown-toc-config
+	numbering=true
+	autoSave=true
+	/vscode-markdown-toc-config -->
+<!-- /vscode-markdown-toc -->
+# <a name='Documentsderfrence'></a>Documents de référence
+
+## 1. <a name='Worfklows'></a>Worfklows
+
+* **Authentification**: [Auth.md](Auth-Specs.md)
+* **Items**: [Item-Specs.md](Item-Specs.md)
+* **PRD et PCD**: [PRD-PCD-Specs.md](PRD-PCD-Specs.md)
+* **Messages et transactions SP**: [Message-SP-Specs.md]
+* **Process et roles**: [Process-Role-Specs.md](Process-Role-Specs.md)
+
+## 2. <a name='Transverse'></a>Transverse
+
+* **Définitions et abréviations.**: [Specs-Definition.md]
+* **Exigences de sécurité**: [Specs-Security.md](Specs-Security.md)
+* **Code**: [Specs-Code.md]
+* **Maintenance, environnement de déploiement**: [Specs-Deployment.md]
+* **References**: [Specs-References.md](Specs-References.md)
+
+## 3. <a name='Diagrammesdarchitecture'></a>3.3. Diagrammes d'architecture
+
+* **Diagramme d'architecture montrant les composants principaux du système de login.**
+[SheatSheet 4NK](https://cryptpad.fr/diagram/#/2/diagram/view/3UG+7ccutUvJlwJ1-bR40RhgOA+rb5eEmw42wtkN19A)

doc/Item-Specs.md

@@ -25,23 +25,7 @@
 
 ## 3. <a name='Documentsderfrence'></a>3. Documents de référence
 
-### 3.1. <a name='Worfklows'></a>Worfklows
+Voir [Doc_references.md](Doc_references.md).
-
-* **Authentification**: Auth-Specs.md
-* **PRD et PCD**: PRD-PCD-Specs.md
-* **Messages et transactions SP**: Message-SP-Specs.md
-* **Process et roles**: Process-Role-Specs.md
-
-### 3.2. <a name='Transverse'></a>Transverse
-
-* **Définitions et abréviations.**: Specs-Definition.md
-* **Exigences de sécurité**: Specs-Security.md
-* **Code**: Specs-Code.md
-* **Maintenance, environnement de déploiement**: Specs-Deployment.md
-* **References**: Specs-References.md
-
-* **Diagramme d'architecture montrant les composants principaux du système de login.**
-[SheatSheet 4NK](https://cryptpad.fr/diagram/#/2/diagram/view/3UG+7ccutUvJlwJ1-bR40RhgOA+rb5eEmw42wtkN19A)
 
 ### 3.3. <a name='TypesdItems'></a>Types d'Items
 

doc/Messages-SP-Specs.md

@@ -0,0 +1,291 @@
+<!-- vscode-markdown-toc -->
+* 1. [Objectif](#Objectif)
+* 2. [Portée](#Porte)
+* 3. [3. Documents de référence](#Documentsderfrence)
+  * 3.1. [Worfklows](#Worfklows)
+  * 3.2. [Transverse](#Transverse)
+* 4. [Authentification des utilisateurs](#Authentificationdesutilisateurs)
+* 5. [Connexion via des tiers](#Connexionviadestiers)
+* 6. [Fonctionnalité de récupération de mot de passe](#Fonctionnalitdercuprationdemotdepasse)
+* 7. [Gestion de session basée sur un cache](#Gestiondesessionbasesuruncache)
+* 8. [Gestion des clés de l'identité (aussi les clés des transactions SP)](#GestiondesclsdelidentitaussilesclsdestransactionsSP)
+  * 8.1. [Génération des clés privées (création des identités numériques)](#Gnrationdesclsprivescrationdesidentitsnumriques)
+    * 8.1.1. [HD Wallet (BIP32 + BIP44)](#HDWalletBIP32BIP44)
+    * 8.1.2. [Connexions avec une identité crée (`recover`)](#Connexionsavecuneidentitcrerecover)
+* 9. [Exemples de Code](#ExemplesdeCode)
+
+<!-- vscode-markdown-toc-config
+	numbering=true
+	autoSave=true
+	/vscode-markdown-toc-config -->
+<!-- /vscode-markdown-toc --># Auth - Specs
+
+## 1. <a name='Objectif'></a>Objectif
+
+## 2. <a name='Porte'></a>Portée
+
+## 3. <a name='Documentsderfrence'></a>3. Documents de référence
+
+#Voir [Doc_references.md](Doc_references.md).
+
+## 4. <a name='Authentificationdesutilisateurs'></a>Authentification des utilisateurs
+
+Les utilisateurs doivent pouvoir s'authentifier en utilisant un mot de passe et les données `exif` d'une image dite de login mise en cache dans IndexedDB pour les navigateurs et les applications mobiles, sinon en mémoire pour tous autres dispositifs dont l'IoT et une partie venant de membres choisi par les gestionnaires des membres des `process`.
+
+Le système utilisera les clés cryptographiques de Bitcoin pour une authentification sécurisée via un HD Wallet transparent, intégrant le concept de Silent Payment pour éviter la réutilisation d'adresses. Les annuaires présents par rôles dans les contrats sont des listes d'adresses Silent Payments avec leurs `third parties`.
+
+Les utilisateurs sont reconnus par une adresse Silent Payment dans un ou plusieurs rôles dans un process. Ces process préalablement publiés et relayés par les relais décrivent les conditions de validation des identités. Par process, les identités appelées techniquement `member`.
+
+Chaque relais permet d'accéder à la liste des process, de créer, recomposer (`recover`) et révoquer (`revoke`) une identité, et de la compléter par process dans lequel l'utilisateur a un rôle (`onboarding`).
+
+## 5. <a name='Connexionviadestiers'></a>Connexion via des tiers
+
+Le système offrira la possibilité de se connecter via des services tiers (tels que OAuth2, avec Google, GitHub, etc.), permettant une intégration fluide avec les écosystèmes existants sans dégrader l'expérience utilisateur.
+
+Pour cela, les flux de 4NK agissent en "proxy" transparent devant les flux API des services concernés, et les tokens d'accès sont ajoutés aux données de `member`.
+
+## 6. <a name='Fonctionnalitdercuprationdemotdepasse'></a>Fonctionnalité de récupération de mot de passe
+
+En cas d'oubli de mot de passe, les utilisateurs pourront récupérer leur accès depuis une nouvelle identité (`recover`) après avoir révoqué l'ancienne identité, via un processus sécurisé, impliquant une vérification d'identité et l'échange de secrets chiffrés conformément aux protocoles établis.
+
+Une image de révocation est générée à la création d'une identité pour pouvoir dépenser un UTXO dit alors de révocation, avec les flux PCD et PRD correspondants.
+
+## 7. <a name='Gestiondesessionbasesuruncache'></a>Gestion de session basée sur un cache
+
+Le système ne maintiendra pas de session traditionnelle sur le serveur. La navigation de l'utilisateur persiste grâce à un cache local dans IndexedDB ou en mémoire, avec une politique de sécurité stricte forçant la resaisie du mot de passe après un rafraîchissement de la page ou une inactivité prolongée, déterminée par une durée maximale sans login.
+
+## 8. <a name='GestiondesclsdelidentitaussilesclsdestransactionsSP'></a>Gestion des clés de l'identité (aussi les clés des transactions SP)
+
+### 8.1. <a name='Gnrationdesclsprivescrationdesidentitsnumriques'></a>Génération des clés privées (création des identités numériques)
+
+#### 8.1.1. <a name='HDWalletBIP32BIP44'></a>HD Wallet (BIP32 + BIP44)
+
+Les transactions SP ont besoin de 2 clés privées Bitcoin, l'une critique sur la dépense des jetons, l'autre qui lève la confidentialité (partageable dans certains cas) :
+
+* **Clé de dépense** : la clé qui prouve sa détention par la capacité de dépenser un UTXO d'une transaction SP.
+* **Clé de scan** : la clé qui permet de détecter qu'une transaction SP nous est destinée.
+
+Il y a 3 paires de ces clés privées :
+
+* **2 paires pour les données exif de l'image de login** : l'une pour les transactions sur le signet, l'autre pour le mainnet.
+* **1 paire pour les données exif de l'image de révocation** : pour les transactions de révocation sur le signet.
+
+Techniquement ces clés sont identiques et générées de la même manière.
+
+Chaque clé possède un chemin de dérivation spécifique et propre à son réseau (`/0` pour le mainnet, `/44` pour le signet).
+
+Afin de constituer un portefeuille unique de clés du signet et du mainnet on génère un HD Wallet.
+
+L'aléatoire pour la génération des clés est critique, et il convient de choisir un aléatoire fourni par une librairie de référence (`rand` pour le Rust).
+
+Dans l'ordre on génère donc :
+
+1. Clé privée de dépense du login du signet `spend_recover`.
+2. Clé privée de scan du login du signet `scan_recover`.
+3. Clé privée de dépense de révocation du signet `spend_revoke`.
+4. Clé privée de scan de révocation du signet `scan_revoke`.
+5. Clé privée de dépense mainnet `spend_mainnet`.
+6. Clé privée de scan du mainnet `scan_mainnet`.
+
+##### Génération des adresses SP
+
+Le relais partage leur liste de relais au setup du SDK (Wasm), cette liste est stockée en cache sous forme d'objets `SharedPeer`.
+
+Afin d'obtenir les premiers `UTXO` indispensables pour créer les adresses SP, l'utilisateur parcourt la liste de relais `SharedPeer` et se connecte à chacun via un `MessageConnect`.
+
+Ces relais envoient en retour quelques jetons sur une adresse dite de faucet `faucet_sp_address` (adresses publiques classiques générées depuis ces clés privées).
+
+Avec ces `UTXO` et les clés de dépense et de scan, on génère 1 `adresse SP` pour le réseau signet et 1 pour le réseau mainnet et chacun pour leurs clés de login et de révocation.
+
+Dans l'ordre on génère donc :
+
+1. Adresse `faucet_sp_address` de login du signet.
+2. Adresse `faucet_sp_address` de révocation du signet.
+3. Adresse `faucet_sp_address` du mainnet.
+
+Puis on se connecte aux relais selon (on se connecte à plusieurs relais afin de pallier aux indisponibilités éventuelles ou au manque de jetons éventuel sur le relai) :
+
+1. `MessageConnect` sur le relai 1 avec l'adresse `faucet_sp_address` de login du signet.
+2. `MessageConnect` sur le relai 1 avec l'adresse `faucet_sp_address` de révocation du signet.
+3. `MessageConnect` sur le relai 1 avec l'adresse `faucet_sp_address` du mainnet.
+4. `MessageConnect` sur le relai 2 avec l'adresse `faucet_sp_address` de login du signet.
+5. `MessageConnect` sur le relai 2 avec l'adresse `faucet_sp_address` de révocation du signet.
+6. `MessageConnect` sur le relai 2 avec l'adresse `faucet_sp_address` du mainnet.
+7. `MessageConnect` sur le relai 3 avec l'adresse `faucet_sp_address` de login du signet.
+8. `MessageConnect` sur le relai 3 avec l'adresse `faucet_sp_address` de révocation du signet.
+9. `MessageConnect` sur le relai 3 avec l'adresse `faucet_sp_address` du mainnet.
+10. `MessageConnect` sur le relai 4 avec l'adresse `faucet_sp_address` de login du signet.
+11. `MessageConnect` sur le relai 4 avec l'adresse `faucet_sp_address` de révocation du signet.
+12. `MessageConnect` sur le relai 4 avec l'adresse `faucet_sp_address` du mainnet.
+
+Puis on génère les adresses SP :
+
+1. Adresse `id_SP` de login du signet depuis `spend_recover` et `scan_recover` et une des transactions des faucets depuis une transaction vers `faucet_sp_address` de login du signet.
+2. Adresse `id_SP` de révocation du signet depuis `spend_revoke` et `scan_revoke` et une des transactions des faucets depuis une transaction vers `faucet_sp_address` de révocation du signet.
+3. Adresse `id_SP` du mainnet depuis `spend_mainnet` et `scan_mainnet` et une des transactions des faucets depuis une transaction vers `faucet_sp_address` du mainnet.
+
+##### Clés de dépense du signet du login
+
+Le relais partage leur liste de process au setup du SDK (Wasm), cette liste est stockée en cache sous forme d'objets `SharedProcess`.
+
+La clé privée de dépense du signet du login est la clé principale pour forger les identités.
+
+Cette clé est d'abord décomposée, avant d'être partiellement distribuée. Voici les principales étapes :
+
+1. Cette clé sera scindée en 2 parties (à la moitié de la longueur de leur représentation hexadécimale) :
+
+    1.1. `Part1`, c'est la partie qui sera chiffrée (AES-GCM 256 bits) par le mot de passe et stockée en cache dans une image dite de login.
+
+    1.2. `Part2`, c'est la partie qui sera décomposée par un Shamir Secret Sharing, chiffrée pour chaque partie par le mot de passe et distribuées en 1 pour 1 aux membres actuels du rôle de gestionnaire des membres du process.
+
+2. Une `préimage Part1EncHash` qui identifie l'utilisateur est générée par le hash (SHA 256) de la `Part1` et du mot de passe de l'utilisateur.
+
+3. Création d'un `PRDKeyBackup` par membre (1 shard par membre), par PRD :
+
+    3.1. Génération d'une clé de chiffrement dite `sp_shared_secret` qui sera transmise dans le Diffie-Hellman de la transaction SP.
+
+    3.2. Définition de l'attribut `device_footprint_enc_by_sp_shared_secret` et chiffrement avec `sp_shared_secret`.
+
+    3.3. Définition de l'attribut `part_1_enc_hash_enc_by_sp_shared_secret` et chiffrement avec `sp_shared_secret`.
+
+    3.4. Définition de l'attribut `shard_enc_by_sp_shared_secret` et chiffrement avec `sp_shared_secret`.
+
+4. Création des messages de type `Message` correspondant aux PRD, envoi des messages aux relais connectés.
+
+Dans l'ordre on réalise donc les opérations suivantes donc :
+
+1. Split de `spend_recover`.
+2. Chiffrement AES de `Part1`.
+3. Mise en cache de `Part1Enc`.
+4. Création de la préimage
+5. Chiffrement AES de `Part2`.
+6. Sharding de `Part2Enc`.
+
+Puis  (exemple avec 2 membres) :
+
+1. Création de `PRDKeyBackup` à destination de membre 1 de la liste des membres (adresse SP) du rôle `Member` du `Process`.
+2. Création de `PRDKeyBackup` à destination de membre 2 de la liste des membres (adresse SP) du rôle `Member` du `Process`.
+3. Création de `Message` du `PRDKeyBackup` à destination de membre 1.
+4. Création de `Message` du `PRDKeyBackup` à destination de membre 2.
+5. Envoi de la transaction SP du `Message` du `PRDKeyBackup` à destination de membre 1.
+6. Envoi de la transaction SP du `Message` du `PRDKeyBackup` à destination de membre 2.
+7. Envoi du `Message` du `PRDKeyBackup` à destination de membre 1 sur le relai 1.
+8. Envoi du `Message` du `PRDKeyBackup` à destination de membre 1 sur le relai 2.
+9. Envoi du `Message` du `PRDKeyBackup` à destination de membre 1 sur le relai 3.
+10. Envoi du `Message` du `PRDKeyBackup` à destination de membre 1 sur le relai 4.
+11. Envoi du `Message` du `PRDKeyBackup` à destination de membre 2 sur le relai 1.
+12. Envoi du `Message` du `PRDKeyBackup` à destination de membre 2 sur le relai 2.
+13. Envoi du `Message` du `PRDKeyBackup` à destination de membre 2 sur le relai 3.
+14. Envoi du `Message` du `PRDKeyBackup` à destination de membre 2 sur le relai 4.
+
+##### Étape d'`update` et envoi de l'objet `ItemMember` pour `Onboarding`
+
+Pour être `onboard` dans un process, c'est-à-dire avoir un rôle, il faut s'ajouter dans la liste des membres du process.
+
+Cela signifie envoyer un `PRDUpdate` avec une nouvelle version du PCD de la liste des membres, contenant notre objet `ItemMember` complet. Ce PRD devra recevoir des membres du rôle `Member` du process les `PRDResponse` correspondant aux critères de validation du `process`.
+
+C'est à ce moment-là que l'on transmet toutes les clés privées dans l'objet `ItemMember`, en tant que donnée privée (chiffrée par la clé de dépense du signet) dans un PCD (et les `PRDUpdate` correspondant).
+
+Les adresses SP correspondantes sont aussi transmises en tant que données publiques, ainsi que l'adresse SP de la clé de dépense du login du signet.
+
+Avant de choisir un process pour continuer l'update de la nouvelle identité :
+
+1. Scan `Nakamoto` des transactions, récupération dans les transactions SP sur Adresse `id_SP` de login du signet, lecture du `RequestHash` de l`output 3` correspondant aux `PRDResponse` à recevoir ou déjà reçus.
+2. Réception des `PRDResponse` et contrôle de la valeur des signatures (`hash_sig_value`), attente du `validation_timeout` du rôle `Member` du `process` et validation ou non des `PRDKeyBackup`.
+3. Attente et réception des `pcd_reference_hash` des `PRDResponse` reçus avec le PCD des membres du processus (liste de `itemMember`).
+4. Recomposition de la clé selon :
+4.1. Déchiffrement par le mot de passe de `Part1Enc` depuis le cache.
+4.2. Déchiffrement par secret partagé de chaque shard reçu dans `id_shard_info_enc_by_shared_secret` des `PRDResponse` de chaque member du role `Member`du process.
+4.3 Recomposition de `Part2Enc` et déchiffrement par le mot de passe
+4.4 Concaténation de `Part1` et `Part2`
+
+Demande d'update de la liste des membres (PCD) d'un process (exemple avec 2 membres):
+
+1. Création et envoi des `PRDKeyHello`.
+1.1. Création de `PRDKeyHello` à destination de membre 1 de la liste des membres (adresse SP) du rôle `Member` du `Process`.
+1.2. Création de `PRDKeyHello` à destination de membre 2 de la liste des membres (adresse SP) du rôle `Member` du `Process`.
+1.3. Création de `Message` du `PRDKeyHello` à destination de membre 1.
+1.4. Création de `Message` du `PRDKeyHello` à destination de membre 2.
+1.5. Envoi de la transaction SP du `Message` du `PRDKeyHello` à destination de membre 1.
+1.6. Envoi de la transaction SP du `Message` du `PRDKeyHello` à destination de membre 2.
+1.7. Envoi du `Message` du `PRDKeyHello` à destination de membre 1 sur le relai 1.
+1.8. Envoi du `Message` du `PRDKeyHello` à destination de membre 1 sur le relai 2.
+1.9. Envoi du `Message` du `PRDKeyHello` à destination de membre 1 sur le relai 3.
+1.10. Envoi du `Message` du `PRDKeyHello` à destination de membre 1 sur le relai 4.
+1.11. Envoi du `Message` du `PRDKeyHello` à destination de membre 2 sur le relai 1.
+1.12. Envoi du `Message` du `PRDKeyHello` à destination de membre 2 sur le relai 2.
+1.13. Envoi du `Message` du `PRDKeyHello` à destination de membre 2 sur le relai 3.
+1.14. Envoi du `Message` du `PRDKeyHello` à destination de membre 2 sur le relai 4.
+2. Réception des `PRDResponse` en réponse aux `PRDKeyHello` et mise à jour des listes depuis les `PCD` correspondants.
+3. Création d'un `ItemMember` correspondant à l'utilisateur avec les clés chiffrées (hors clés de révocation) dans la partie data des métadonnées privées et les adresses SP dans les données publiques.
+4. Création d'une nouvelle version du PCD avec l'ajout de l'`ItemMember` créé.
+5. Parcours des membres du rôle `Member` et envoi des `PRDUpdate`.
+6. Attente de la validation (`PRDResponse`) du `PRDUpdate`.
+7. Redirection vers la page du process sur le relai.
+
+##### Clés de révocation (`revoke`)
+
+Les clés de l'image de révocation sont chiffrées par le mot de passe (ou pas, en option) et stockées directement dans les données exifs de l'image de révocation. Les adresses SP correspondantes sont aussi inscrites dans les données exif.
+
+L'envoi d'une révocation est identique à la création d'une nouvelle adresse via les `PRDKeyBackup` mais la transaction SP est envoyée depuis l'adresse de révocation (la clé aura dû être chargée au préalable depuis l'interface).
+
+##### Clés de third parties
+
+En plus, on peut générer d'autres paires de clés de dépense et de scan qui seront à exporter vers d'autres dispositifs pour du 2FA, avec leurs UTXO.
+
+Pour cela, il faut se connecter aux relais avec les adresses de faucet de ces nouvelles clés (adresses publiques classiques générées depuis ces clés privées). Comme pour les clés de `recover` et de `revoke`.
+
+Les adresses SP de ces clés sont ajoutées avec les labels et éventuellement les empreintes des dispositifs correspondants dans l'objet `ItemMember`.
+
+Ces clés sont générées lors de l'update d'un membre, avec déjà une identité créée sur un process, à la validation de l'update il est possible de télécharger des images correspondantes (clés + hash du process) dans une interface 2FA.
+
+Lorsqu'une transaction est reçue sur l'application de 2FA, celle-ci demande de confirmer ou non. Si il y a une confirmation dans l'interface alors une transaction SP est envoyée au dispositif initial, en dépensant l'UTXO reçue et avec les mêmes Hash dans les outputs que la transaction reçue afin que le dispositif initial puisse collecter les PRD concernés.
+
+#### 8.1.2. <a name='Connexionsavecuneidentitcrerecover'></a>Connexions avec une identité crée (`recover`)
+
+Comme pour la création de compte, les relais partagent leur liste de relais et de process au setup du SDK (Wasm), ces listes sont stockées en cache sous forme d'objets `SharedPeer` et `SharedProcess`.
+
+Afin d'obtenir de nouveaux UTXO indispensables pour créer les adresses SP, l'utilisateur parcourt la liste de relais `SharedPeer` et se connecte à chacun via un `MessageConnect`.
+
+Dans l'ordre on réalise les opérations suivantes :
+
+1. Récupération de Part1Enc en cache
+2. Création de la pré-image avec le mot de passe
+
+Puis :
+
+1. Création de `PRDKeyHello` à destination de membre 1 de la liste des membres (adresse SP) du rôle `Member` du `Process`.
+2. Création de `PRDKeyHello` à destination de membre 2 de la liste des membres (adresse SP) du rôle `Member` du `Process`.
+3. Création de `Message` du `PRDKeyHello` à destination de membre 1.
+4. Création de `Message` du `PRDKeyHello` à destination de membre 2.
+5. Envoi de la transaction SP du `Message` du `PRDKeyHello` à destination de membre 1.
+6. Envoi de la transaction SP du `Message` du `PRDKeyHello` à destination de membre 2.
+7. Envoi du `Message` du `PRDKeyHello` à destination de membre 1 sur le relai 1.
+8. Envoi du `Message` du `PRDKeyHello` à destination de membre 1 sur le relai 2.
+9. Envoi du `Message` du `PRDKeyHello` à destination de membre 1 sur le relai 3.
+10. Envoi du `Message` du `PRDKeyHello` à destination de membre 1 sur le relai 4.
+11. Envoi du `Message` du `PRDKeyHello` à destination de membre 2 sur le relai 1.
+12. Envoi du `Message` du `PRDKeyHello` à destination de membre 2 sur le relai 2.
+13. Envoi du `Message` du `PRDKeyHello` à destination de membre 2 sur le relai 3.
+14. Envoi du `Message` du `PRDKeyHello` à destination de membre 2 sur le relai 4.
+
+1. Scan `Nakamoto` des transactions, récupération dans les transactions SP sur Adresse `id_SP` de login du signet, lecture du `RequestHash` de l`output 3` correspondant aux `PRDResponse` à recevoir ou déjà reçus.
+2. Réception des `PRDResponse` et contrôle de la valeur des signatures (`hash_sig_value`), attente du `validation_timeout` du rôle `Member` du `process` et validation ou non des `PRDKeyHello`.
+3. Attente et réception des `pcd_reference_hash` des `PRDResponse` reçus avec le PCD des membres du processus (liste de `itemMember`).
+4. Recomposition de la clé selon :
+4.1. Déchiffrement par le mot de passe de `Part1Enc` depuis le cache.
+4.2. Déchiffrement par secret partagé de chaque shard reçu dans `id_shard_info_enc_by_shared_secret` des `PRDResponse` de chaque member du role `Member`du process.
+4.3 Recomposition de `Part2Enc` et déchiffrement par le mot de passe
+4.4 Concaténation de `Part1` et `Part2`
+
+Demande d'update de la liste des membres (PCD) d'un process :
+
+1. Création et envoi des `PRDList`.
+2. Réception des `PRDResponse` en réponse aux `PRDList` et mise à jour des listes depuis les `PCD` correspondants.
+3. Création d'un `ItemMember` correspondant à l'utilisateur avec les clés chiffrées (hors clés de révocation) dans la partie data des métadonnées privées et les adresses SP dans les données publiques.
+4. Création d'une nouvelle version du PCD avec l'ajout de l'`ItemMember` créé.
+5. Redirection vers la page du process sur le relai.
+
+## 9. <a name='ExemplesdeCode'></a>Exemples de Code
+
+Extraits de code illustrant l'utilisation des PCD et PRD dans des scénarios réels.

doc/PRD-PCD-Specs.md

@@ -31,23 +31,7 @@ La spécification couvre la conception, le développement, et l'application prat
 
 ## 3. <a name='Documentsderfrence'></a>3. Documents de référence
 
-### 3.1. <a name='Worfklows'></a>Worfklows
+Voir [Doc_references.md](Doc_references.md).
-
-* **Authentification**: Auth-Specs.md
-* **Items**: Item-Specs.md
-* **Messages et transactions SP**: Message-SP-Specs.md
-* **Process et roles**: Process-Role-Specs.md
-
-### 3.2. <a name='Transverse'></a>Transverse
-
-* **Définitions et abréviations.**: Specs-Definition.md
-* **Exigences de sécurité**: Specs-Security.md
-* **Code**: Specs-Code.md
-* **Maintenance, environnement de déploiement**: Specs-Deployment.md
-* **References**: Specs-References.md
-
-* **Diagramme d'architecture montrant les composants principaux du système de login.**
-[SheatSheet 4NK](https://cryptpad.fr/diagram/#/2/diagram/view/3UG+7ccutUvJlwJ1-bR40RhgOA+rb5eEmw42wtkN19A)
 
 ### 3.3. <a name='StructuredesPCDetPRDetdeleurattributgnriqueRequest'></a>Structure des PCD et PRD et de leur attribut générique Request
 

doc/Process-roles-Specs.md

@@ -40,23 +40,7 @@ Cette section vise à présenter en détail les Documents de Contrat Portable (P
 
 ## 3. <a name='Documentsderfrence'></a>3. Documents de référence
 
-### 3.1. <a name='Worfklows'></a>Worfklows
+Voir [Doc_references.md](Doc_references.md).
-
-* **Authentification**: Auth-Specs.md
-* **Items**: Item-Specs.md
-* **Messages et transactions SP**: Message-SP-Specs.md
-* **PRD et PCD**: PRD-PCD-Specs.md
-
-### 3.2. <a name='Transverse'></a>Transverse
-
-* **Définitions et abréviations.**: Specs-Definition.md
-* **Exigences de sécurité**: Specs-Security.md
-* **Code**: Specs-Code.md
-* **Maintenance, environnement de déploiement**: Specs-Deployment.md
-* **References**: Specs-References.md
-
-* **Diagramme d'architecture montrant les composants principaux du système de login.**
-[SheatSheet 4NK](https://cryptpad.fr/diagram/#/2/diagram/view/3UG+7ccutUvJlwJ1-bR40RhgOA+rb5eEmw42wtkN19A)
 
 ## 4. <a name='RlesetSous-Rles'></a>Rôles et Sous-Rôles
 

doc/Specs-Code.md

@@ -17,6 +17,11 @@
 	/vscode-markdown-toc-config -->
 <!-- /vscode-markdown-toc --># Specs - Code
 
+
+## 1. <a name='Documentsderfrence'></a>Documents de référence
+
+Voir [Doc_references.md](Doc_references.md).
+
 ## 1. <a name='Gestiondeserreurs'></a>Gestion des erreurs
 
 Les processus doivent continuer malgré des "sous" traitements/threads en échec et les fonctions doivent être `catch` si il y a une possiblité d'interuption.

doc/Specs-Datas.md

@@ -99,6 +99,10 @@
 	/vscode-markdown-toc-config -->
 <!-- /vscode-markdown-toc --># Specs - Datas
 
+## 1. <a name='Documentsderfrence'></a>Documents de référence
+
+Voir [Doc_references.md](Doc_references.md).
+
 ## 1. <a name='Conditions'></a>Conditions
 
 ### 1.1. <a name='ConditionCap'></a>ConditionCap

doc/Specs-Definition.md

@@ -10,6 +10,10 @@
 	/vscode-markdown-toc-config -->
 <!-- /vscode-markdown-toc --># Définitions et abréviations
 
+## 1. <a name='Documentsderfrence'></a>Documents de référence
+
+Voir [Doc_references.md](Doc_references.md).
+
 ## 1. <a name='Spcifique4NK'></a>Spécifique 4NK
 
 * **4NK**: Système décentralisé innovant basé sur les principes du web 5, centré sur la sécurité des données et l'identité numérique.

doc/Specs-Deployment.md

@@ -1,4 +1,6 @@
 <!-- vscode-markdown-toc -->
+* 1. [Documents de référence](#Documentsderfrence)
+* 2. [2. Code repository](#Coderepository)
 
 <!-- vscode-markdown-toc-config
 	numbering=true
@@ -6,4 +8,12 @@
 	/vscode-markdown-toc-config -->
 <!-- /vscode-markdown-toc --># Specs - Maintenance, environnement de déploiement
 
+# Deployement
+
+## 1. <a name='Documentsderfrence'></a>Documents de référence
+
+Voir [Doc_references.md](Doc_references.md).
+
+## 2. <a name='Coderepository'></a>2. Code repository
+
 Voir le git du projet `infra_node`.

doc/Specs-References.md

@@ -1,9 +1,10 @@
 <!-- vscode-markdown-toc -->
-* 1. [AES & Quantum resistant](#AESQuantumresistant)
+* 1. [Documents de référence](#Documentsderfrence)
-* 2. [Bitcoin Silent Payment](#BitcoinSilentPayment)
+* 2. [AES & Quantum resistant](#AESQuantumresistant)
-* 3. [Bitcoin wallet](#Bitcoinwallet)
+* 3. [Bitcoin Silent Payment](#BitcoinSilentPayment)
-* 4. [Data anchoring](#Dataanchoring)
+* 4. [Bitcoin wallet](#Bitcoinwallet)
-* 5. [Layers](#Layers)
+* 5. [Data anchoring](#Dataanchoring)
+* 6. [Layers](#Layers)
 
 <!-- vscode-markdown-toc-config
 	numbering=true
@@ -12,11 +13,15 @@
 <!-- /vscode-markdown-toc -->
 # Specs - References
 
-## 1. <a name='AESQuantumresistant'></a>AES & Quantum resistant
+## 1. <a name='Documentsderfrence'></a>Documents de référence
+
+Voir [Doc_references.md](Doc_references.md).
+
+## 2. <a name='AESQuantumresistant'></a>AES & Quantum resistant
 
 * <https://medium.com/asecuritysite-when-bob-met-alice/why-is-128-bit-aes-insecure-for-a-quantum-computer-but-256-bit-is-not-814a8a9d6500>
 
-## 2. <a name='BitcoinSilentPayment'></a>Bitcoin Silent Payment
+## 3. <a name='BitcoinSilentPayment'></a>Bitcoin Silent Payment
 
 * <https://github.com/bitcoin/bitcoin/issues/28536>
 * <https://github.com/genjix/bips/blob/master/bip-stealth.mediawiki>
@@ -26,18 +31,18 @@
 * <https://gnusha.org/taproot-bip-review/2020-01-23.log>
 * <https://gist.github.com/RubenSomsen/be7a4760dd4596d06963d67baf140406>
 
-## 3. <a name='Bitcoinwallet'></a>Bitcoin wallet
+## 4. <a name='Bitcoinwallet'></a>Bitcoin wallet
 
 * <https://river.com/learn/terms/b/bip-44-derivation-paths-for-p2pkh>
 * <https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md>
 * <https://github.com/bitcoin/bips/blob/master/bip-0380.mediawiki>
 
-## 4. <a name='Dataanchoring'></a>Data anchoring
+## 5. <a name='Dataanchoring'></a>Data anchoring
 
 * <https://petertodd.org/2016/opentimestamps-announcement#fnref:rewrite>
 * <https://www.lopp.net/bitcoin-information/data-anchor.html>
 
-## 5. <a name='Layers'></a>Layers
+## 6. <a name='Layers'></a>Layers
 
 * <https://blackpaper.rgb.tech/consensus-layer/3.-client-side-validation/3.1.-proof-of-publication>
 * <https://milan2016.scalingbitcoin.org/files/presentations/D2%20-%20A%20-%20Peter%20Todd.pdf>

doc/Specs-Security-confidentiality.md

@@ -1,36 +1,37 @@
 <!-- vscode-markdown-toc -->
-* 1. [Détails de conception](#Dtailsdeconception)
+* 1. [Documents de référence](#Documentsderfrence)
-* 1. [Mot de passe](#Motdepasse)
+* 2. [Détails de conception](#Dtailsdeconception)
-* 2. [Cache](#Cache)
+* 3. [Mot de passe](#Motdepasse)
-* 3. [Chiffrement des communications](#Chiffrementdescommunications)
+* 4. [Cache](#Cache)
-* 4. [Confidentialité des PCD et PRD](#ConfidentialitdesPCDetPRD)
+* 5. [Chiffrement des communications](#Chiffrementdescommunications)
-* 5. [Confidentialité des messages sur les relais](#Confidentialitdesmessagessurlesrelais)
+* 6. [Confidentialité des PCD et PRD](#ConfidentialitdesPCDetPRD)
-* 6. [Clé de chiffrement robuste](#Cldechiffrementrobuste)
+* 7. [Confidentialité des messages sur les relais](#Confidentialitdesmessagessurlesrelais)
-* 6.1. [Résistance aux attaques cryptanalytiques](#Rsistanceauxattaquescryptanalytiques)
+* 8. [Clé de chiffrement robuste](#Cldechiffrementrobuste)
-* 6.2. [Diffusion et confusion](#Diffusionetconfusion)
+  * 8.1. [Résistance aux attaques cryptanalytiques](#Rsistanceauxattaquescryptanalytiques)
-* 6.3. [Non-linéarité](#Non-linarit)
+  * 8.2. [Diffusion et confusion](#Diffusionetconfusion)
-* 7. [Fonctions de hashage](#Fonctionsdehashage)
+  * 8.3. [Non-linéarité](#Non-linarit)
-* 8. [Exigences génériques](#Exigencesgnriques)
+* 9. [Fonctions de hashage](#Fonctionsdehashage)
-* 8.1. [Pas de secret de la conception](#Pasdesecretdelaconception)
+* 10. [Exigences génériques](#Exigencesgnriques)
-* 8.2. [Validé par la communauté scientifique](#Validparlacommunautscientifique)
+  * 10.1. [Pas de secret de la conception](#Pasdesecretdelaconception)
-* 8.3. [Implémentation correcte](#Implmentationcorrecte)
+  * 10.2. [Validé par la communauté scientifique](#Validparlacommunautscientifique)
-* 8.4. [Détermination](#Dtermination)
+  * 10.3. [Implémentation correcte](#Implmentationcorrecte)
-* 8.5. [Rapidité de calcul](#Rapiditdecalcul)
+  * 10.4. [Détermination](#Dtermination)
-* 8.6. [Diffusion (ou effet avalanche)](#Diffusionoueffetavalanche)
+  * 10.5. [Rapidité de calcul](#Rapiditdecalcul)
-* 8.7. [Résistance aux collisions](#Rsistanceauxcollisions)
+  * 10.6. [Diffusion (ou effet avalanche)](#Diffusionoueffetavalanche)
-* 8.7.1. [Résistance aux collisions faibles](#Rsistanceauxcollisionsfaibles)
+  * 10.7. [Résistance aux collisions](#Rsistanceauxcollisions)
-* 8.7.2. [Résistance aux collisions fortes](#Rsistanceauxcollisionsfortes)
+    * 10.7.1. [Résistance aux collisions faibles](#Rsistanceauxcollisionsfaibles)
-* 8.8. [Résistance à la pré-image](#Rsistancelapr-image)
+    * 10.7.2. [Résistance aux collisions fortes](#Rsistanceauxcollisionsfortes)
-* 8.8.1. [Résistance à la pré-image](#Rsistancelapr-image-1)
+  * 10.8. [Résistance à la pré-image](#Rsistancelapr-image)
-* 8.8.2. [Résistance à la seconde pré-image](#Rsistancelasecondepr-image)
+    * 10.8.1. [Résistance à la pré-image](#Rsistancelapr-image-1)
-* 8.9. [Compression](#Compression)
+    * 10.8.2. [Résistance à la seconde pré-image](#Rsistancelasecondepr-image)
-* 8.10. [Non réversibilité](#Nonrversibilit)
+  * 10.9. [Compression](#Compression)
-* 8.11. [Absence de toute structure prévisible](#Absencedetoutestructureprvisible)
+  * 10.10. [Non réversibilité](#Nonrversibilit)
-* 9. [Gestion sécurisée des clés](#Gestionscurisedescls)
+  * 10.11. [Absence de toute structure prévisible](#Absencedetoutestructureprvisible)
-* 10. [Performance](#Performance)
+* 11. [Gestion sécurisée des clés](#Gestionscurisedescls)
-* 11. [Disponibilité](#Disponibilit)
+* 12. [Performance](#Performance)
-* 12. [Évolutivité](#volutivit)
+* 13. [Disponibilité](#Disponibilit)
-* 13. [Autres Mesures de sécurité](#AutresMesuresdescurit)
+* 14. [Évolutivité](#volutivit)
+* 15. [Autres Mesures de sécurité](#AutresMesuresdescurit)
 
 <!-- vscode-markdown-toc-config
 	numbering=true
@@ -38,9 +39,11 @@
 	/vscode-markdown-toc-config -->
 <!-- /vscode-markdown-toc --># Exigences de sécurité et de confidentialité
 
+## 1. <a name='Documentsderfrence'></a>Documents de référence
 
+Voir [Doc_references.md](Doc_references.md).
 
-###  1. <a name='Dtailsdeconception'></a>Détails de conception
+## 2. <a name='Dtailsdeconception'></a>Détails de conception
 
 Tous les chiffrements symétriques sont opérés avec l'algorithme AES-GCM 256 bits.
 
@@ -48,38 +51,37 @@ Tous les hash sont opérés avec l'algorithme SHA256.
 
 La librairie Rust `Nakamoto`, permet de scanner les blocs (et bientôt la mempool) côté client et de détecter des transactions Bitcoin correspondant aux clés publiques des clés cryptographiques privées du HD Wallet Bitcoin contenant les clés Bitcoin de mainnet et de signet.
 
-##  1. <a name='Motdepasse'></a>Mot de passe
+## 3. <a name='Motdepasse'></a>Mot de passe
 
 Utilisation du mot de passe strictement en mémoire.
 
 Mot de passe fort (18 caractères minimum avec minuscules, majuscules, lettre, nombres, et caractères spéciaux) ou mnémonique de 12 mots à noter ou certificat (ou équivalent) stocké de façon sécurisée.
 
-##  2. <a name='Cache'></a>Cache
+## 4. <a name='Cache'></a>Cache
 
 Stockage sécurisé du cache par un chiffrement par le mot de passe.
 
-##  3. <a name='Chiffrementdescommunications'></a>Chiffrement des communications
+## 5. <a name='Chiffrementdescommunications'></a>Chiffrement des communications
 
 Le chiffrement du transport des données se fait par TLS entre les clients et le noeuds entrants pour palier aux restrictions sur les flux non TLS par les navigateurs et les applications mobiles.
 
 Néanmoins tous les messages chiffrent les PCD et PRD avec une clé de chiffrement conforme aux exigences suivantes et échangée dans le Diffie-Hellman de la transaction SP, en parallèle donc des flux PCD et PRD. Ces clés ne sont accessibles donc qu'avec la clé privée du destinataire ou de l'émetteur, qui ne sont jamais partagées.
 
-##  4. <a name='ConfidentialitdesPCDetPRD'></a>Confidentialité des PCD et PRD
+## 6. <a name='ConfidentialitdesPCDetPRD'></a>Confidentialité des PCD et PRD
 
 Le stockage chiffré de cache est un chiffrement symétrique conformément aux exigences suivantes.
 
 Le chiffrement des PCD est un chiffrement symétrique conformément aux exigences suivantes. Le chiffrement des clés de chiffrement dans les PRD est un chiffrement symétrique conformément aux exigences suivantes selon :
 
-- **Données publiques**: un chiffrement symétrique conformément aux exigences suivantes depuis la `ProcessKey`. Tout le monde peut donc déchiffrer.
+* **Données publiques**: un chiffrement symétrique conformément aux exigences suivantes depuis la `ProcessKey`. Tout le monde peut donc déchiffrer.
 
+* **Données confidentielles avec les membres d'un `role` d'un `process` dans les PCD**: un chiffrement symétrique conformément aux exigences suivantes depuis une clé de chiffrement générée à la volée par champs par items d'une liste d'un PCD.
 
-- **Données confidentielles avec les membres d'un `role` d'un `process` dans les PCD**: un chiffrement symétrique conformément aux exigences suivantes depuis une clé de chiffrement générée à la volée par champs par items d'une liste d'un PCD.
+* **Données confidentielles avec les membres d'un `role` d'un `process` dans les PRD**: un chiffrement symétrique conformément aux exigences suivantes depuis les clés de chiffrement AES-GCM-256  générée à la volée dans les PCD et alors transmises par le PRD, chiffrées par la `KeyConfiditial` d'une transaction `SP`.
 
-- **Données confidentielles avec les membres d'un `role` d'un `process` dans les PRD**: un chiffrement symétrique conformément aux exigences suivantes depuis les clés de chiffrement AES-GCM-256  générée à la volée dans les PCD et alors transmises par le PRD, chiffrées par la `KeyConfiditial` d'une transaction `SP`.
+* **Données privées**: un chiffrement symétrique conformément aux exigences suivantes depuis le chiffrement par la clé de spend de login (`recover`) du signet (voir Login - Specs).
 
-- **Données privées**: un chiffrement symétrique conformément aux exigences suivantes depuis le chiffrement par la clé de spend de login (`recover`) du signet (voir Login - Specs).
+## 7. <a name='Confidentialitdesmessagessurlesrelais'></a>Confidentialité des messages sur les relais
-
-##  5. <a name='Confidentialitdesmessagessurlesrelais'></a>Confidentialité des messages sur les relais
 
 Les PCD et les PRD sont envoyés aux relais dans des enveloppes appelées `Message`.
 
@@ -89,89 +91,89 @@ Tous les `PRD` (sauf les `PRDKeyBackup`), sont confirmés par un et chiffrent le
 
 Les relais peuvent déchiffrer les enveloppes avec la `ProcessKey`, le contenu étant chiffré en plus en fonction des niveaux de confidentialité. L'objectif du chiffrage des enveloppe est de donner, un temps, un coût et une complexité aux analyses systématiques des flux.
 
-##  6. <a name='Cldechiffrementrobuste'></a>Clé de chiffrement robuste
+## 8. <a name='Cldechiffrementrobuste'></a>Clé de chiffrement robuste
 
 La force d'un algorithme de chiffrement symétrique repose largement sur la complexité de sa clé. Une clé plus longue offre généralement une meilleure sécurité. Les tailles de clé typiques pour un chiffrement fort sont de 128 bits, 192 bits, ou 256 bits. Pour l'AES-GCM, les clés de 256 bits sont à ce stade réputées "quantum-resistant" et sont donc à privilégier, elles satisfont aussi les contraintes suivantes.
 
-###  6.1. <a name='Rsistanceauxattaquescryptanalytiques'></a>Résistance aux attaques cryptanalytiques
+### 8.1. <a name='Rsistanceauxattaquescryptanalytiques'></a>Résistance aux attaques cryptanalytiques
 
 Un algorithme fort doit résister à diverses attaques, y compris les attaques par force brute (où un attaquant essaie toutes les clés possibles), les attaques par texte clair connu, les attaques par texte clair choisi, les attaques par texte chiffré choisi, et plus encore. L'AES-GCM les clés de 256 bits n'est pas par design robuste à ces attaques, mais avec une clé suffisamment longue (de longueur quantique) le temps nécessaire est estimé comme équivalent à une résistance.
 
-###  6.2. <a name='Diffusionetconfusion'></a>Diffusion et confusion
+### 8.2. <a name='Diffusionetconfusion'></a>Diffusion et confusion
 
 Ces deux principes, introduits par Claude Shannon, sont essentiels à la sécurité d'un algorithme. La diffusion vise à disperser l'influence d'un seul caractère du texte clair sur de nombreux caractères du texte chiffré, tandis que la confusion vise à complexifier la relation entre la clé de chiffrement et le texte chiffré.
 
-###  6.3. <a name='Non-linarit'></a>Non-linéarité
+### 8.3. <a name='Non-linarit'></a>Non-linéarité
 
 L'algorithme doit incorporer des éléments non linéaires pour contrer les attaques linéaires et différentielles. Cela rend la prédiction du comportement de l'algorithme plus difficile pour un attaquant.
 
-##  7. <a name='Fonctionsdehashage'></a>Fonctions de hashage
+## 9. <a name='Fonctionsdehashage'></a>Fonctions de hashage
 
 Les fonctions de hachage jouent un rôle crucial dans de nombreux domaines de la cryptographie et de la sécurité informatique, notamment dans la vérification de l'intégrité des données, l'authentification, la signature numérique, et la génération de jetons sécurisés. Pour être efficaces et sécurisées, ces fonctions doivent répondre à plusieurs exigences essentielles :
 
-##  8. <a name='Exigencesgnriques'></a>Exigences génériques
+## 10. <a name='Exigencesgnriques'></a>Exigences génériques
 
-###  8.1. <a name='Pasdesecretdelaconception'></a>Pas de secret de la conception
+### 10.1. <a name='Pasdesecretdelaconception'></a>Pas de secret de la conception
 
 La sécurité d'un bon système cryptographique ne doit pas reposer sur le secret de son algorithme (principe de Kerckhoffs) et doit être basée sur des principes cryptographiques éprouvés.
 
-###  8.2. <a name='Validparlacommunautscientifique'></a>Validé par la communauté scientifique
+### 10.2. <a name='Validparlacommunautscientifique'></a>Validé par la communauté scientifique
 
 Un algorithme est considéré comme plus fort s'il a été soumis à l'examen et à l'analyse de la communauté cryptographique internationale, qui cherche des vulnérabilités potentielles.
 
-###  8.3. <a name='Implmentationcorrecte'></a>Implémentation correcte
+### 10.3. <a name='Implmentationcorrecte'></a>Implémentation correcte
 
 Une implémentation fautive d'un algorithme de chiffrement fort peut introduire des vulnérabilités. Il est crucial que l'implémentation soit vérifiée pour être sécurisée. La librairie utilisée doit avoir été l'objet d'un audit ([librairie aes-gcm de rust a été auditée](https://research.nccgroup.com/2020/02/26/public-report-rustcrypto-aes-gcm-and-chacha20poly1305-implementation-review/)).
 
-###  8.4. <a name='Dtermination'></a>Détermination
+### 10.4. <a name='Dtermination'></a>Détermination
 
 Pour toute entrée donnée, la fonction de hachage doit toujours produire la même sortie.
 
-###  8.5. <a name='Rapiditdecalcul'></a>Rapidité de calcul
+### 10.5. <a name='Rapiditdecalcul'></a>Rapidité de calcul
 
 La fonction doit être capable de générer le hachage rapidement, même pour de grandes quantités de données.
 
-###  8.6. <a name='Diffusionoueffetavalanche'></a>Diffusion (ou effet avalanche)
+### 10.6. <a name='Diffusionoueffetavalanche'></a>Diffusion (ou effet avalanche)
 
 Un changement minime dans l'entrée (même un seul bit) doit entraîner un changement significatif et imprévisible dans la sortie. Cela garantit qu'il est difficile de prédire comment la sortie changera en fonction des modifications apportées à l'entrée.
 
-###  8.7. <a name='Rsistanceauxcollisions'></a>Résistance aux collisions
+### 10.7. <a name='Rsistanceauxcollisions'></a>Résistance aux collisions
 
 Il doit être pratiquement impossible de trouver deux entrées distinctes qui produisent la même sortie. Cela se décline en deux sous-catégories :
 
-####  8.7.1. <a name='Rsistanceauxcollisionsfaibles'></a>Résistance aux collisions faibles
+#### 10.7.1. <a name='Rsistanceauxcollisionsfaibles'></a>Résistance aux collisions faibles
 
 Il est difficile de trouver une seconde entrée qui a le même hachage qu'une entrée spécifiée.
 
-####  8.7.2. <a name='Rsistanceauxcollisionsfortes'></a>Résistance aux collisions fortes
+#### 10.7.2. <a name='Rsistanceauxcollisionsfortes'></a>Résistance aux collisions fortes
 
 Il est difficile de trouver deux entrées distinctes qui produisent le même hachage.
 
-###  8.8. <a name='Rsistancelapr-image'></a>Résistance à la pré-image
+### 10.8. <a name='Rsistancelapr-image'></a>Résistance à la pré-image
 
 Pour une sortie de hachage donnée, il doit être difficile de trouver une entrée qui correspond à cette sortie. Cela se décline également en deux sous-catégories :
 
-####  8.8.1. <a name='Rsistancelapr-image-1'></a>Résistance à la pré-image
+#### 10.8.1. <a name='Rsistancelapr-image-1'></a>Résistance à la pré-image
 
 Il est difficile de trouver une entrée qui hache vers une sortie de hachage spécifiée.
 
-####  8.8.2. <a name='Rsistancelasecondepr-image'></a>Résistance à la seconde pré-image
+#### 10.8.2. <a name='Rsistancelasecondepr-image'></a>Résistance à la seconde pré-image
 
 Étant donné une entrée, il est difficile de trouver une autre entrée qui produit le même hachage.
 
-###  8.9. <a name='Compression'></a>Compression
+### 10.9. <a name='Compression'></a>Compression
 
 La fonction de hachage doit pouvoir prendre une entrée de taille arbitraire et produire une sortie de taille fixe.
 
-###  8.10. <a name='Nonrversibilit'></a>Non réversibilité
+### 10.10. <a name='Nonrversibilit'></a>Non réversibilité
 
 Il doit être infaisable de retrouver l'entrée à partir de la sortie du hachage. Cela signifie que la fonction est à sens unique.
 
-###  8.11. <a name='Absencedetoutestructureprvisible'></a>Absence de toute structure prévisible
+### 10.11. <a name='Absencedetoutestructureprvisible'></a>Absence de toute structure prévisible
 
 La fonction de hachage ne doit pas produire des sorties qui montrent des patterns ou des structures prévisibles, quelles que soient les entrées.
 
-##  9. <a name='Gestionscurisedescls'></a>Gestion sécurisée des clés
+## 11. <a name='Gestionscurisedescls'></a>Gestion sécurisée des clés
 
 La manière dont les clés sont générées, stockées, distribuées, révoquées, et détruites est tout aussi importante que l'algorithme de chiffrement lui-même.
 
@@ -181,21 +183,21 @@ Les parties sont pour la moitié stockées dans le contexte utilisateur (chiffr
 
 L'utilisateur seul peut détruire une clé de révocation (`revoke`) ou supprimer l'image de login qui contient la première partie de la clé de login, indispensable pour recomposer sa clé.
 
-##  10. <a name='Performance'></a>Performance
+## 12. <a name='Performance'></a>Performance
 
 Le temps de réponse doit être rapide pour les opérations de login. Ce temps sera estimé de façon empirique au fur et à mesure des implémentations.
 
-##  11. <a name='Disponibilit'></a>Disponibilité
+## 13. <a name='Disponibilit'></a>Disponibilité
 
 La haute disponibilité et la reprise après sinistre sont permises par la redondance des `relais` sans système central ou critique et robustes à la défaillance d'une partie des participants. C'est idem pour la redondance au sein des `membres` des gestionnaires des membres dans les `processus`, qui ont tous des actions égales et robustes à la défaillance d'une partie des participants.
 
 En cas de perte, vol, corruption, ou expiration des clés, l'utilisateur peut de son initiative et en toute autonomie révoquer une identité et en générer une nouvelle.
 
-##  12. <a name='volutivit'></a>Évolutivité
+## 14. <a name='volutivit'></a>Évolutivité
 
 La capacité à gérer une augmentation du nombre d'`utilisateurs` est un équilibre arbitré par les parties prenantes, en fonction du besoin de `relais` et de `membres`. Les parties prenantes ont les moyens d'enrôler par eux-mêmes les relais et les membres par `rôles` et par `process`.
 
-##  13. <a name='AutresMesuresdescurit'></a>Autres Mesures de sécurité
+## 15. <a name='AutresMesuresdescurit'></a>Autres Mesures de sécurité
 
 Les mécanismes de défense contre les vulnérabilités courantes doivent être implémentés (CSRF, XSS).