revolt
revolt copied to clipboard
revoltchat
End-to-end Encryption
need to write out requirements here
TODO: write an RFC (https://github.com/revoltchat/rfcs)
MVP List:
- [ ] ~~OMEMO-style secret chats~~ OpenMLS instead?
- [ ] key verification (verify users through trusted channel, can use emojis like Matrix)
- [ ] server key storage (generate a mnemonic to encrypt and store keys on server)
Additional Requirements:
- [ ] Cross device signing (i.e. https://element.io/blog/e2e-encryption-by-default-cross-signing-is-here/)
- [ ] New device trust flow (allow a trusted device to confirm a new session)
- [ ] Expiring / ephemeral messages
- [ ] E2EE Voice Calls
- [ ] E2EE File Uploads
Note: figure out if it is feasible to encrypt Saved Notes, would need to sync it to the server
DM's for opting-in or out if you want it to be encrypted or not with the visuals showing that it's indeed encrypted or unencrypted as in how it works for Matrix. Telegram has this but only on mobile by opting through Mobile, but this should be on all platforms which would be a game changer. Also, one more request and that is deleting DM's on both sides like how it's done on Telegram Both encrypted and unencrypted way also when it's deleted from Both sides it should be deleted from Server-side too.
I think i'd be best to have e2ee by default since alot of people are also unaware of the perks it can have on your privacy and security. Or at least give the user a small tour on what e2ee is and have them decide if they want it for all DMs. I do agree with the telegram DM deletion method as it helps delete dms easier without worry of the other user snooping through old history.
E2EE is a must for DMs! at least and by default
Agreed, E2EE for servers is redundant as servers are public. DMs, groups and notes should be E2EE.
E2EE should be enabled by default in dms (and groups hopefully later), and if there is any reason to not have it enabled by default, then it has been implemented wrong. I also think that it should not be as intrusive as the matrix protocol's implementation and I think it should also not be optional. If non-E2EE and E2EE chats coexist then it means there will be double the areas of development which is just weird, and some users may misunderstand what E2EE is when browsing settings. Anyways, love this project, hope E2EE happens.
Question, if they keys are staying on the server wouldn't that garner fear that revolt devs can just take any keys and look into coversations at any time? If I am wrong clarification is appreciated.
Question, if they keys are staying on the server wouldn't that garner fear that revolt devs can just take any keys and look into coversations at any time? If I am wrong clarification is appreciated.
No, the server would receive the public keys of each user but only the users would have the full information needed to decrypt
E2EE is a must for DMs! at least and by default
Agreed, E2EE for servers is redundant as servers are public. DMs, groups and notes should be E2EE.
...Not all servers are public, what about private ones?
E2EE is a must for DMs! at least and by default
Agreed, E2EE for servers is redundant as servers are public. DMs, groups and notes should be E2EE.
...Not all servers are public, what about private ones?
that could possibly be a good feature but that depends if group chats are only limited to 10 users. If its considered, i think a message should appear to the owner explaining its possible draw backs and pros (i.e. server unable to be posted on the discovery but the main revolt server are unable to see your meesages)
Implementing encryption for a server with a large amount of people is a bigger ordeal than doing the same for dms or groups. For dms, it is merely about exchanging keys and then just using them when sending messages. With groups, it is a little different, but for large servers I think a different protocol would be needed to add encryption. If servers had like 20 members for example, it would be easy, but if they had 1000+, then you would have to be careful not to stress any hardware too much with the protocol used. Adding encryption to dms and groups would definitely be a very strong point to revolt, and the platform would gain more support from the privacy community. The most "complex" part of adding encryption is merging chats where plaintext and encrypted messages have been sent.
agreed, as the point of servers are "public" by design and if you want a private group then thats what the group dms are for (depending on the group user limit if there is one) e2ee groups don't really make sense in practice.
...
that could possibly be a good feature but that depends if group chats are only limited to 10 users. If its considered, i think a message should appear to the owner explaining its possible draw backs and pros (i.e. server unable to be posted on the discovery but the main revolt server are unable to see your meesages)
agreed, as the point of servers are "public" by design and if you want a private group then thats what the group dms are for (depending on the group user limit if there is one) e2ee groups don't really make sense in practice.
Even if this is the case, there's multiple reasons why a small group would want a server instead - Voice calls don't alert everyone in the group, multiple channels, custom emojis (if and when that ever becomes a thing), permissions, etc.
I do agree with @peepopoggers though and this should be limited to 30, maybe 50 members max.
@peepopoggers Messaging Layer Security supports arbitrarily large groups.
https://messaginglayersecurity.rocks/mls-protocol/draft-ietf-mls-protocol.html https://messaginglayersecurity.rocks/mls-architecture/draft-ietf-mls-architecture.html
Maybe this is an idea... encryption could be enabled by default for servers with under 50-100 members. After that, it could be converted to plaintext. In settings server owner could toggle a hard stop so encryption always stays. I guess this is just theory, but what would a true limit to matrix be?
After that, it could be converted to plaintext.
Security vulnerability: mass join spambots to force downgrade any chat.
Once enabled, there is supposed to be no way back from E2EE to non-E2EE.
Yeah, you are right. Idk the technical limitations of this stuff. For example, would e2ee be possible for servers with 5000, or even 50,000 members?
i'd say e2ee shall be in dms, groups and notes. Groups should at least be able to hold 20 people. But at the end of the day it all depends on the hardware and money they have.
@peepopoggers Yes, Matrix for example has E2EE rooms with more than 50k members. And underlying key sharing protocols support arbitrarly large groups. However, the larger the group, the more keyshare messages you will need.
@peepopoggers Yes, Matrix for example has E2EE rooms with more than 50k members. And underlying key sharing protocols support arbitrarly large groups. However, the larger the group, the more keyshare messages you will need.
yes but encrypted rooms take about a minute to send messages and idk if its their servers or the protocol itself.
i'd say e2ee shall be in dms, groups and notes. Groups should at least be able to hold 20 people. But at the end of the day it all depends on the hardware and money they have.
Make a priority for groups, dms and notes (also make it default mode when stable), and servers could be experimental (not default) until hopefully refined to a well working state.
@peepopoggers Yes, Matrix for example has E2EE rooms with more than 50k members. And underlying key sharing protocols support arbitrarly large groups. However, the larger the group, the more keyshare messages you will need.
yes but encrypted rooms take about a minute to send messages and idk if its their servers or the protocol itself.
I think it would be cool to implement it like the way I said above, experimental (not a default) and then it can be optimized hopefully. I am not sure how matrix implements encryption, but there are definitely tricks to make things faster :L
I would like to add encryption via DM's should be mandatory meaning it's automatically added without opt out
Encryption should be prioritized...
I think there are more important things we should address currently, like getting core features in that people expect from other platforms.
I'm also not going to rush building encryption either because there's only one chance to get it right, and I don't want to get it wrong.