Pour faire suite aux idées développées dans un autre fil, voici un début de protocole permettant de chiffrer les messages. Je le propose au moins pour la messagerie privée. Pour les commentaires de tx ça reste à discuter.
Le dépôt contient la description formelle du protocole et une implémentation Rust.
Il est adapté au stockage en datapod. Il reste à définir les métadonnées nécessaires pour adresser et retrouver un message (e.g. par clé publique de destinataire et identifiant de conversation ou de bloc et d’extrinsic).
Il faut stocker quelque part un état secret (clés privées nécessaires au chiffrement/déchiffrement des futurs messages). Ça peut être chiffré sur un serveur public centralisé ou un datapod, ou en local (dans ce cas la conversation est accessible uniquement sur cet appareil).
Le premier message envoyé entre deux comptes contient obligatoirement pas mal de métadonnées cryptographiques (même si le message est en clair) pour permettre au destinataire de répondre de manière sécurisée, mais les messages suivants n’en contiennent pas s’ils sont en clair.
Côté UI
J’ai essayé de rendre le protocole simple à utiliser et à intégrer dans une UI compréhensible.
Envoyer un premier message
Vous envoyez un message à un compte qui ne vous en a encore jamais envoyé, ou qui ne vous fait pas confiance.
- Voulez-vous chiffrer le message ? Le destinataire pourra choisir de le rendre public de manière irrécusable.
Recevoir un message
Vous avez reçu un message.
- Le mode de sécurité de ce message est parmi :
- Public : Google peut le lire.
- Privé : seul vous pouvez le lire.
- Privé irrécusable : seul vous pouvez le lire, mais vous pouvez le signaler publiquement.
- Bouton “Signaler ce message” (si le mode de sécurité est Privé, un humain doit évaluer la bonne foi du signalement)
- Bouton “Empêcher ce compte de m’envoyer des messages privés sauf si irrécusables” (il faudrait trouver une meilleure formulation)
Envoyer un message
Vous envoyez un message à un compte qui vous en a déjà envoyé.
- Voulez-vous chiffrer le message ? Le destinataire pourra choisir de le rendre public de manière irrécusable.
- Si oui, voulez-vous le rendre irrécusable ?
Pourquoi si compliqué (forward secrecy)
C’est nécessaire si on veut que les messages restent confidentiels même en cas de fuite de la clé privée (c’est la forward secrecy). En supprimant les clés temporaires, on exerce un droit à l’oubli potentiellement inviolable.
Commentaires de transaction
Ce protocole peut aussi servir aux commentaires de transaction, mais l’obligation de messages bidirectionnels pour profiter de la forward secrecy est contraignante. En recevant un commentaire de transaction, il faut pouvoir faire les actions listées ci-dessus.
Il faut voir comment indexer les commentaires pour pouvoir répondre à un commentaire et établir une conversation sécurisée, même si les transactions sont unidirectionnelles.
On peut aussi unifier les commentaires et les messages (un commentaire étant un message indexé à un extrinsic).
Si c’est trop contraignant, on peut abandonner la forward secrecy et garder l’irrécusabilité obligatoire. Ainsi il n’y aurait plus d’état à stocker.