End-to-end Encryption

[insertish]

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

[insertish]

Note: figure out if it is feasible to encrypt Saved Notes, would need to sync it to the server

[spronu]

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.

[Flam3z]

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.

[UnixPhonez]

E2EE is a must for DMs! at least and by default

[Flam3z]

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.

[peepo5]

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.

[erkinalp]

@insertish MLS is stronger than olm that is used by OMEMO and MegOLM.

[Flam3z]

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.

[Zomatree]

@Flam3z The private key wouldnt be stored on the server, so no.

[Flam3z]

Ty for the quick response

[Evilhotdog]

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

[ggtylerr]

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?

[Flam3z]

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)

[peepo5]

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.

[Flam3z]

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.

[ggtylerr]

...

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.

[erkinalp]

@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

[peepo5]

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?

[erkinalp]

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.

[peepo5]

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?

[Flam3z]

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.

[erkinalp]

@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.

[Flam3z]

@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.

[peepo5]

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.

[peepo5]

@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

[Flam3z]

we'll see when the milestone gets there

[UnixPhonez]

this will bring more users

[UnixPhonez]

I would like to add encryption via DM's should be mandatory meaning it's automatically added without opt out

[FillingTheVoidOnYT]

Encryption should be prioritized...

[insertish]

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.

[insertish]

I would like to add encryption via DM's should be mandatory meaning it's automatically added without opt out

I don't know how the final implementation will look, but I'm personally leaning towards having a toggle between the two which also allows us to:

• Keep old DM contents
• Allow users to have message history on server (one possibility with encrypted messages is to do an encrypted server-side backup but it can introduce holes or potentially lose data, not to mention that all messages would need to be merged and all of that data needs to be saved locally)

[FillingTheVoidOnYT]

I would like to add encryption via DM's should be mandatory meaning it's automatically added without opt out

I don't know how the final implementation will look, but I'm personally leaning towards having a toggle between the two which also allows us to:

• Keep old DM contents
• Allow users to have message history on server (one possibility with encrypted messages is to do an encrypted server-side backup but it can introduce holes or potentially lose data, not to mention that all messages would need to be merged and all of that data needs to be saved locally)

okay understandable, but let me ask you this when messages are purged in an channel are they deleted on the server side or just kept in plain text despite being deleted in their channel they correspond to

[erkinalp]

@insertish Could a Matrix-style encapsulation work? Matrix encrypts E2EE message event body and wraps it in a whole event body. That would allow enabling encryption from a certain point on, without losing the ability to read messages prior to enabling E2EE.

[insertish]

I would like to add encryption via DM's should be mandatory meaning it's automatically added without opt out

I don't know how the final implementation will look, but I'm personally leaning towards having a toggle between the two which also allows us to:

• Keep old DM contents
• Allow users to have message history on server (one possibility with encrypted messages is to do an encrypted server-side backup but it can introduce holes or potentially lose data, not to mention that all messages would need to be merged and all of that data needs to be saved locally)

okay understandable, but let me ask you this when messages are purged in an channel are they deleted on the server side or just kept in plain text despite being deleted in their channel they correspond to

Messages are (and have always been) deleted completely and immediately, with the exception of attachments which can take up to a minute to delete because the file server needs to delete it from S3.

[therealonlygithub1]

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.

although it's redundant for public servers, there should still be the option for servers in general as not all servers are public. Many servers would like the encryption part it would actually bring more companies to revolt as many companies operate under an NDA contract and encryption would be one less checkmark they don't have to leave unchecked

[ghost]

For me Since more and more law require privacy, it's better to enable E2EE everywhere like that the services is covered against breach of law they don't even aware of.

[erkinalp]

that the services is covered against breach of law they don't even aware of.

Can you explain it further with references to actual legal decisions supporting this?

[ghost]

that the services is covered against breach of law they don't even aware of.

Can you explain it further with references to actual legal decisions supporting this?

One good example would be the last EU irish fine in the case where meta (facebook) didn't prevent enough data scraping.

So there is no law Today that can create problem (in my knowledge), but tomorow, if a country pass a law, and one of their citizen use your services ?

It's why i would advocate to enable it everywhere like that you are covered and nobody can tell later that Revolt don't have done "enough" to protect their user data.

[go-compile]

E2EE would be great, however it will require a upgrade to user authentication.

Currently, Revolt sends the password to the server, if the current authentication system was to be used with E2EE this would compromise all value added by E2EE. This is because the public/private key pairs will be encrypted on the server using a key derived from the user's password. Hence fourth, without a authentication overall E2EE would be vulnerable to MiTM attacks and a malicious server exposing keys to retrieve plaintext communications.

Solution

Authentication will need to use a Zero Knowledge Proof (ZKP), this would project the password from both MiTM attacks and a malicious servers. A augmented PAKE (Password Authenticated Key Exchange) - would allow for the server to prove the user knows their password without ever seeing their password, not even in registration.

A scheme such as OPAQUE (https://blog.cloudflare.com/opaque-oblivious-passwords/) or Secure Remote Password protocol (SRP) would be the best choice for this. Moreover, these schemes are used by Protonmail (https://proton.me/blog/encrypted-email-authentication), Tutanota etc. Additionally, further key derivation via the use of a KDF, e.g. HKDF, should be used to produce two unique keys, one for authentication, the other for encrypting the private key.

[MasicoreLord]

Scared how proposed laws like the current Earn It Act (USA), the Online Safety Bill (UK) or etc. well impact this, assuming they pass eventually.

[insertish]

Just making a note here that this will need to be converted to an RFC at some point before further work can be done.

E2EE would be great, however it will require a upgrade to user authentication.

Definitely, I will add this to our internal queue to look into.

Scared how proposed laws like the current Earn It Act (USA), the Online Safety Bill (UK) or etc. well impact this, assuming they pass eventually.

If passed, that's just more motivation to work on this, I will never recognise any law that bans / hampers encryption to a degree that it is useless.

[MasicoreLord]

Just making a note here that this will need to be converted to an RFC at some point before further work can be done.

E2EE would be great, however it will require a upgrade to user authentication.

Definitely, I will add this to our internal queue to look into.

Scared how proposed laws like the current Earn It Act (USA), the Online Safety Bill (UK) or etc. well impact this, assuming they pass eventually.

If passed, that's just more motivation to work on this, I will never recognise any law that bans / hampers encryption to a degree that it is useless.

While true, in countries like the USA for example, you'd risk losing liability protections and be treated as a publisher rather than a platform, liable for anything you happen to have on your service.

[MasicoreLord]

Since the main instance isn't USA based it may be safe from that particular threat.

Not sure what countries like the UK were threatening with.

So if you go through with it, make it something an instance can easily disable.

[vertigo220]

Worthless image and video files should not be sent to encrypted channels

Not sure if you meant all image and video files are worthless and not necessary to encrypt or that specifically ones that are worthless don't need it, but if the former, that's simply not true, and if the latter, it becomes an issue of how to tell between ones that do and do not need it and running the risk of accidentally not encrypting ones that should be. Encryption isn't exactly an expensive operation, so I see no reason to not just encrypt everything.

[c0fe]

Is there interest in implementing Signal protocol as the encryption? It can be adjusted to be used without phone numbers, it is proven to be secure unlike Matrix, supports media, video chatting and group chat.

[Pantyhose-X]

Clients may implement E2EE in the future, but servers will never implement E2EE, I've already asked them at revolt.

Using all 3 services Revolt, Lightspeed, & Gifbox is giving Revolt a lot of your data. Your chats, images, & videos all logged stored for whatever purpose they see fit. Lets go back to the site & talk about the part of the slogan where it says "you can be sure your conversations are confidential & data is secure." Revolt doesn't have E2EE (end to end encryption) so confidential is a lie because everyone's chat is stored & any staff member can read from the beginning to the present.

They advertised Revolt had E2EE in it's first year which was a lie it was on a table of discussions to be implemented in future rewrite of the client. They spend more time playing video games, making jokes condescending America, sidetracking on multiple projects simultaneously, generating memes with Stable Diffusion, & doing school work then working on the software.

When it comes to self hosting Revolt they did everything to deter people from self hosting because they didn't want other people running their own instance. They wouldn't support anyone who asked for help which goes against the open source license policy as you must provide instructions & support for your open software your distributing. If anyone asked you were interrogated for asking they were afraid people would have no reason to go to Revolt.chat if they help people setup theirs. There were also certain parts of Revolt that were closed-sourced like server discovery & more they did this to ensure people would not have a full functioning chat service ready to go & you would have to do some manual implementations such as creating your own server discovery & making it work within the app. They did this on purpose to spitefully stop people from self-hosting who wants a discord clone with no server discovery & you have to make one yourself?

The staff is LGBTQIA so anything in that direction = instant ban but condescending America is alright 100%. You could even make your account username as Ihateamericanscum & guess what you wouldn't get banned or forced to change your username but if your name was Ihateeurope or LGBT you would be immediately banned or forced to change username before you got to say hello. They also have a serious hatred for the AM|PM format I don't understand why there is such a great hatred for it that they have purposely refused to implement it & argue with people to just learn 24/7 time format.

Some Criticism Source https://0.0g.gg/?f47f5f63dd027f2f#85cGkzR2V7z4R1t6agghesCvxsY9DicwDpQ6m14Wq5KD

[Zomatree]

Clients may implement E2EE in the future, but servers will never implement E2EE, I've already asked them at revolt.

This is complete miss-information, we have always planned and still plan on implementing end to end encryption fully into revolt.

[insertish]

There's a lot more nuance here that people miss, it's not that servers can't be encrypted, it's that it may be technically infeasible (very very large servers reaching thousands of users) or useless in some cases (servers with public invites). The simple answer is no, but the actual answer is that work needs to be done to figure out how it'll actually work within servers because it's not as simple as DMs.

[ghost]

There's a lot more nuance here that people miss, it's not that servers can't be encrypted, it's that it may be technically infeasible (very very large servers reaching thousands of users) or useless in some cases (servers with public invites). The simple answer is no, but the actual answer is that work needs to be done to figure out how it'll actually work within servers because it's not as simple as DMs.

but why not starting by implementing a "simple" DM, and follow with a double method, one based on small and medium server and later push very large, because, 90% of your user's server will fall into small and medium.

[Rexogamer]

I don't really see how that addresses the issues Insert raised..?