End-to-end Encryption about revolt HOT 43 OPEN

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

from revolt.

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.

from revolt.

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.

from revolt.

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

from revolt.

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.

from revolt.

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

from revolt.

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.

from revolt.

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.

from revolt.

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.

from revolt.

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.

from revolt.

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?

from revolt.

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

from revolt.

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.

from revolt.

we'll see when the milestone gets there

from revolt.

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

from revolt.

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.

from revolt.

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.

from revolt.

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.

from revolt.

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

from revolt.

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.

from revolt.

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

from revolt.

Ty for the quick response

from revolt.

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)

from revolt.

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.

from revolt.

...

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.

from revolt.

@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

from revolt.

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?

from revolt.

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?

from revolt.

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.

from revolt.

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

from revolt.

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

from revolt.

@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

from revolt.

this will bring more users

from revolt.

Encryption should be prioritized...

from revolt.

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)

from revolt.

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

from revolt.

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

from revolt.

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.

from revolt.

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?

from revolt.

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.

from revolt.

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.

from revolt.

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.

from revolt.

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.

from revolt.