Colby Serpađź’ˇ on Nostr: I like the ART (Asynchronous Ratcheting Tree) of MLS. It indeed can handle larger ...
I like the ART (Asynchronous Ratcheting Tree) of MLS. It indeed can handle larger scale group chats better than Signal and the like. I've been hunting for a suitable option to decentralize Discord.
There might be imperfect ways to solve the two disadvantages.
Clients have to store decrypted messages when keys become useless as new ones are created. This creates a risk of data loss since the data is stored locally, not decentralized across relays. You can't put the decrypted data on a relay because then the relay could read the messages.
One solution could be taking all your decrypted messages and encrypting them with a new key, one that's not part of the ART. This key would be unique to the user. Then, the user could encrypt all these decrypted messages with that new key and store the encrypted data archive on relays. That way, even if the user loses their device, the encrypted messages would still be on relays, provided they've backed up that single key.
To tackle the other disadvantage, we can piggyback off the solution to the last disadvantage. New users joining the group chat could ask the people who invited them to the group chat for a copy of their encrypted archive of decrypted previous messages. The inviters could delete messages they don't want to share, but the user could request a copy from multiple group chat participants to mitigate this risk. If all older members do this “sharing” for newer members, then the newish members should still be able to share the oldest messages with the latest joining members.
There might be imperfect ways to solve the two disadvantages.
Clients have to store decrypted messages when keys become useless as new ones are created. This creates a risk of data loss since the data is stored locally, not decentralized across relays. You can't put the decrypted data on a relay because then the relay could read the messages.
One solution could be taking all your decrypted messages and encrypting them with a new key, one that's not part of the ART. This key would be unique to the user. Then, the user could encrypt all these decrypted messages with that new key and store the encrypted data archive on relays. That way, even if the user loses their device, the encrypted messages would still be on relays, provided they've backed up that single key.
To tackle the other disadvantage, we can piggyback off the solution to the last disadvantage. New users joining the group chat could ask the people who invited them to the group chat for a copy of their encrypted archive of decrypted previous messages. The inviters could delete messages they don't want to share, but the user could request a copy from multiple group chat participants to mitigate this risk. If all older members do this “sharing” for newer members, then the newish members should still be able to share the oldest messages with the latest joining members.
quoting note1qyq…r68dI agree we need real private messages and groups.
I’ve looked at lots of ways to do this and I believe this is most promising.
https://p2panda.org/specification/encryption
We’ll need to figure out how for clients to store a set of keys for the groups they’re in. We can do it by encrypting a key collection in an event for the client itself.
MLS is a pretty well thought out of way of doing encrypted groups. In particular p2panda has found a way to do it in a decentralized architecture where the servers simply are dumb data stores like exists with nostr.
From the notes:
Private groups with Sender Ratchet Secrets
Ephemeral AEAD secrets, derived from MLS Secret Tree of current group epoch, used on a per-message base, gives Forward Secrecy (FS) and Post-Compromise Security (PCS).
Advantages:
* Provides strong security for any size of group, even very large groups
* Every message is encrypted with an individual key, attackers will not be able to read past data or future data when a key got compromised
Disadvantages:
* Members joining a group later will not be able to decrypt past data
* Clients have to store decrypted messages somewhere on their end as keys get useless soon