L’idée générale ça serait de créer deux utilisateurs et de donner la clefs à tout les membres du groupe. Qd tu envoies un message tu fais un DM entre ses deux utilisateurs en tirant au hasard l’expéditeur pour que d’un point de vue extérieur ça ait l’air d’une conversation par DM classique entre deux utilisateurs et personne ne peut connaître les participants du message. Cela serait un canal de discussion qui serait le group chat.
A l’intérieur de se canal, les messages doivent être signés avec la clef privée NOSTR des utilisateurs pour qu’on sachent qui parle et que se soit infalsifiable.
Également je propose de crypter tout les messages via RSA ou ElGamal grâce à PGP. Car on peut faire du multisig 1 of n se qui est particulièrement adapté. Ces clefs publiques peuvent être échangées via le réseau de DM NOSTR classique, pas dans le canal, directement entre les utilisateurs.
Ainsi, une personne qui récupérerait les clef du canal de discussion récupérerait juste des messages crypté avec aucune info sur les destinataires ni les expéditeurs. Juste du RSA ou du ElGamal.
Le seul moyen de crack ce truc est de recup la clef privée d’un des participants, mais c’est le cas de n’importe quel group chat.
Pour la forward secrecy, je propose qu’une nouvelle clef RSA ou ElGamal soit échangée par DM entre les participants en dehors du canal, par DM to le X message en fonction du niveau de forward secrecy dont on a besoin.
🔸Aucune modification du protocole n’est requise.
🔸Seul les clients doivent mettre en place cette mécanique.
🔸Je pense même à dev un client qui fait uniquement ça… mais malheureusement avec le bébé, j’ai pas le temps.
Laurent Coin Su
npub1za…k3f95
2023-08-19 18:35:37
in reply to nevent1q…gfrn
Author Public Key
npub1zayt792jcz2qcz59snyrj560zl3jnfkpdzmu9yyzuuvwm563a0tq7k3f95Published at
2023-08-19 18:35:37Event JSON
{
"id": "4869d7e1b637e4b1bcab8bb3b07cb0c832a3cc016dc5c8c0b88f483ff91aea74",
"pubkey": "1748bf1552c0940c0a8584c839534f17e329a6c168b7c29082e718edd351ebd6",
"created_at": 1692470137,
"kind": 1,
"tags": [
[
"e",
"b4ce49f50c351faba62d029d215d7a1373706533f69ebdcc10cde8850ad03974",
""
],
[
"e",
"d83c6b1c0af5b0b25f3563a5a1977e6faebc8be29d3844ccfd1bbc5268c46ebb"
],
[
"p",
"460c25e682fda7832b52d1f22d3d22b3176d972f60dcdc3212ed8c92ef85065c"
],
[
"p",
"1c6b3be353041dd9e09bb568a4a92344e240b39ef5eb390f5e9e821273f0ae6f"
]
],
"content": "L’idée générale ça serait de créer deux utilisateurs et de donner la clefs à tout les membres du groupe. Qd tu envoies un message tu fais un DM entre ses deux utilisateurs en tirant au hasard l’expéditeur pour que d’un point de vue extérieur ça ait l’air d’une conversation par DM classique entre deux utilisateurs et personne ne peut connaître les participants du message. Cela serait un canal de discussion qui serait le group chat.\n\nA l’intérieur de se canal, les messages doivent être signés avec la clef privée NOSTR des utilisateurs pour qu’on sachent qui parle et que se soit infalsifiable.\n\nÉgalement je propose de crypter tout les messages via RSA ou ElGamal grâce à PGP. Car on peut faire du multisig 1 of n se qui est particulièrement adapté. Ces clefs publiques peuvent être échangées via le réseau de DM NOSTR classique, pas dans le canal, directement entre les utilisateurs. \n\nAinsi, une personne qui récupérerait les clef du canal de discussion récupérerait juste des messages crypté avec aucune info sur les destinataires ni les expéditeurs. Juste du RSA ou du ElGamal.\n\nLe seul moyen de crack ce truc est de recup la clef privée d’un des participants, mais c’est le cas de n’importe quel group chat.\n\nPour la forward secrecy, je propose qu’une nouvelle clef RSA ou ElGamal soit échangée par DM entre les participants en dehors du canal, par DM to le X message en fonction du niveau de forward secrecy dont on a besoin.\n\n🔸Aucune modification du protocole n’est requise.\n🔸Seul les clients doivent mettre en place cette mécanique.\n🔸Je pense même à dev un client qui fait uniquement ça… mais malheureusement avec le bébé, j’ai pas le temps.",
"sig": "3e3cbc3d670917a33b0e7ffd0fb12961090caf042ea2be581975d510e0446cbac021910a892f6b470abf303135f7e9fada3d50c18f2895b850187a6ebfd0e430"
}