Je relance le sujet puisque ça concernera les datapods.
Je n’aborde pas les multisignatures ni le déchiffrement à seuil, c’est assez compliqué comme ça. (un jour !)
Niveaux de sécurité
Il y a plusieurs niveaux de sécurité adaptés à différents usages. Disons que A (Anatole) envoie un message M à B (Bernadette).
Notes :
- Ce raisonnement s’étend à tout type de message, pas seulement aux commentaires de tx.
- Je donne des cas d’usage non exhaustifs pour prouver la pertinence d’implémenter ces niveaux de sécurité.
- La payload finale est nécessairement signée par A, pour satisfaire l’antispam.
sign(x) est le couple de x et de la signature de x par la clé privée de A.crypt(x) est le chiffré de x pour la clé privée de B.
Signature à clé publique
Description : sign(A)
Propriétés : Tout le monde a la preuve que A a envoyé M à B, et que B y a accès. B a la preuve que le message est intègre (non modifié) et authentique (écrit par A).
Cas d’usage : dépenses d’une asso
Signature à clé publique + Chiffrement
Description : sign(crypt(sign(M)))
Propriétés : Idem, mais seule B connaît M. B peut révéler publiquement M et prouver que A en est l’auteur.
Cas d’usage : B n’a pas sollicité la transaction de la part de A, les deux ne se font pas confiance a priori. B peut donc accuser publiquement A de harcèlement ou autre, grâce à la signature.
La signature “extérieure” sert au datapod. Elle est suffisante pour que B puisse s’assurer de l’intégrité et de l’authenticité de M. La signature “intérieure” (qui n’est accessible qu’après déchiffrement) sert à B pour prouver publiquement l’authenticité et l’intégrité.
Il me semble dangereux d’autoriser des messages chiffrés sans cette signature “intérieure”, car cela permettrait du spam généralisé impossible à dénoncer preuve à l’appui.
Chiffrement authentifié
Description : Un échange de secret partagé K est nécessaire au préalable (Diffie-Hellman).
sign(AE(K, M))
(où AE(k, x) est le chiffrement symétrique authentifié par la clé k du message x, par exemple AES-AEAD)
Propriétés : Tout le monde sait que A a envoyé un message à B. Seule B connaît M ainsi que sa preuve d’intégrité et d’authenticité. B ne peut prouver à personne que A est l’auteur de M. La responsabilité de A n’est toujours pas prouvée même si la clé privée de B et K sont révélées. Si le chiffrement symétrique est bien choisi, un même K peut servir plusieurs fois.
Cas d’usage : Transaction d’ordre privé entre deux personnes se faisant au moins un peu confiance.
L’échange Diffie-Hellman peut prendre la forme d’une “demande de contact” dans l’UI. La demande contient un facteur, la réponse positive aussi. Le secret partagé peut soit être stocké chiffré dans un datapod, soit être conservé dans l’appareil, selon le besoin. On peut s’inspirer de Matrix qui permet de stocker ses clés dans l’appareil et de les partager avec ses autres appareils.
Suppression
On parlait des modalités de suppression des données à caractère personnel. Le cas d’une communication est particulier, car le destinataire pourrait aussi vouloir supprimer la donnée (ce qui pourrait aussi accuser réception), ou au contraire pourrait vouloir que A ne puisse pas effacer le message.
Dans le niveau Chiffrement authentifié, je ne vois pas de raison à l’interdire. Le message est de toute façon inutile à d’autres personnes que A et B. Aucune preuve publique n’est détruite par l’effacement.
Dans le niveau Signature à clé publique + Chiffrement :
- si A efface avant réception par B, personne ne saura jamais M.
- si A efface après réception par B, B pourra toujours prouver publiquement que A a dit M.
- si B efface, cela peut-il gêner A ? (vraie question, je ne sais pas encore
) 
Dans le niveau Signature à clé publique : (raisonnement peu rigoureux, probablement sujet à plus de discussion)
- si M a porté quelconque préjudice, alors il a été lu, et donc peu importe quand A le supprime, des gens ont la preuve qu’il a écrit M.
- sinon, c’est un cas où la suppression par A ne devrait pas poser problème.
- si B le supprime, alors A ne peut plus prouver qu’il avait écrit M à la date d’envoi, à moins qu’il puisse reconstruire le message d’origine et tomber sur le même cid (puisque le cid reste public après suppression il me semble).
Dans certains cas il peut être utile que les datapods (ou d’autres services) signent tous les cid des contenus publiés, dès leur publication, si le timestamp est suffisamment récent. Cela permettrait de prouver que tel message n’a pas été publié a posteriori et antidaté. Cette preuve (signature d’une dizaine de membres différents) serait plus fiable que la simple règle de pin individuelle aux datapods.
oui, c’est important ça fait partie des fonctionnalités appréciées de la Ğ1 et beaucoup de réflexions aboutissent non seulement à la nécessité de conserver cette fonctionnalité mais également de la soumettre au consensus de la blockchain.