End-to-end Encryption #207
Comments
|
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. |
|
@insertish MLS is stronger than olm that is used by OMEMO and MegOLM. |
|
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. |
|
@Flam3z The private key wouldnt be stored on the server, so no. |
|
Ty for the quick response |
No, the server would receive the public keys of each user but only the users would have the full information needed to decrypt |
...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. |
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 |
|
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? |
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. |
yes but encrypted rooms take about a minute to send messages and idk if its their servers or the protocol itself. |
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. |
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 |
|
we'll see when the milestone gets there |
|
this will bring more users |
|
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. |
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. |
|
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. |
This comment was marked as resolved.
This comment was marked as resolved.
This is complete miss-information, we have always planned and still plan on implementing end to end encryption fully into revolt. |
|
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). |
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. |
|
I don't really see how that addresses the issues Insert raised..? |
it's help to do the requirement step by step, by starting by the "easiest" (1 to 1 discussion), and continue after, because here many ask THE solution that work everywhere, and we see in Whatsapp / Signal case, that this "one solution" do not exist yet, so if you don't start simple you will never finish this work. |
|
Whatsapp and Signal do client fanout with pairwise channels, not true group key establishment. |
Was an example to make understand my point not really was accurate, I can use element if you prefer |
|
Any progress on this ticket? |
Matrix isn't very good security wise, Signal is significantly better. Matrix is right up next to plaintext, while it isn't nothing it is pretty close to nothing in terms of security/privacy. |
|
@insertish I would suggest using Signal protocol for this. |
|
@c0fe That protocol does not scale well. |
|
@erkinalp the limits as far as I am aware of is at a 1,000 at the moment. Last I heard was that there was work towards increasing that. Yeah that's a limit, but it still far better to offer that than something that is inherently broken in terms of security. |
|
@c0fe You keep referring to Matrix as broken, etc, but I see no evidence of that. I looked into it pretty extensively a while back, and again a bit the other day based on your comment, and while it's not audited to the same extent as Signal and does have some issues, AFAICT it's far from "broken" or "next to plaintext." Care to elaborate? |
Actually matrix is quite broken in fact that it happen so often that group encryption broke and need manual intervention to fix so it's not quite suitable for the use in revolt |
|
@vertigo220 the problems with Matrix protocol is that there are numerous security problems that are found by researchers. We aren't even talking about one big issue, say Specter we are talking multiple of these issues being found in terms of how the implementation is done, encryption/decryption and so forth. In other words Matrix protocol is rich in vulnerabilities, people find lots of them and they are all high severity. |
|
Again, I've looked into this, and these statements seem exaggerated. There were a handful of flaws found in 2022 which were responsibly disclosed and, AFAICT, handled appropriately by the developers and fixed in a reasonable time. There was one in 2021 that was a flaw with some clients and not the protocol and that was fixed. And there was an attack in 2019 where malicious actors gained access to unencrypted messages and to password hashes and access tokens which, while far from ideal, isn't really that big a deal if you use a decent password, and I don't see anything about any attacks since. So yeah, while it's had some issues, nothing jumps out as being all that terrible and I'd say it's far from broken or "rich in vulnerabilities" with people findings "lots of them." And of course it requires manual intervention to fix them, but the key is they're being fixed. Sure, as I said before, Signal has been more thoroughly audited and has a better track record, but it's not perfect, either, and IIRC vulnerabilities have been found with it as well (I highly doubt it hasn't had any). If perfect were a 10, Signal might be an 8 and Matrix a 6, whereas Discord is a 0. So between using the Signal protocol and Matrix protocol, as far as security is concerned, sure, go with Signal, but if it has limitations and doesn't provide useful features the Matrix protocol does, I don' think it's necessary to avoid using Matrix, as it's still very good security-wise, and Revolt, being intended as a Discord replacement (i.e. a casual chat client mainly for gaming) needs to make sure it can do that job more than it needs to ensure the most bulletproof encryption possible. People looking for that can just use Signal. And I certainly don't think making statements that Matrix is totally broken and riddled with issues is accurate or fair, to Matrix itself or to users looking for something to use. While not perfect, and not something that should probably be used to transmit highly sensitive info or by someone looking to hide from governments, I'd say it's plenty good enough to maintain privacy. Unless I'm missing something, but I did ask for elaboration and didn't receive any specifics, and I haven't been able to find anything on my own so far. |
You actually never used matrix it seem because having to restart a new group because the encryption have broken everything is an horror, and debug one user who is the only one to have problems is annoying as hell for me me matrix protocol is far from being stable enough to be used by revolt |
Okay, so now your true motives/feelings have come to light. Actually, yes, I've been using it for the past year or so (and after trying, and being disappointed by, Revolt, BTW), and certainly not without issues, but overall it's worked quite well, actually better than Signal did when I used it. I'm not particularly for or against either, I just know there aren't a lot of options out there, and Matrix and Signal both have their pros and cons, and personally I prefer Matrix for usability and, while probably not quite as secure as Signal, it's secure enough. You, on the other hand, seem to dislike it because of issues you've experienced while using it, and you're turning that into arguing that it's not secure, which are two different things. Matrix has a long way to go, but frankly so does Signal, and I don't think Matrix is completely broken, certainly not with respect to its encryption, and I've seen nothing here to support that idea, just generalized talk with no specifics, followed by assumptive statements like this. I just want a secure, usable protocol that I can use to chat with and call friends and family, and after trying and giving up on Signal, Discord, Revolt, Guilded, and a few others, I've found Matrix to be the best fit for that. As I've said, it's not perfect by any means, and I don't have any personal attachment/connection to it and would be very interested to know if there are any significant issues with it (hence my asking for clarification on such suggestive comments here), but absent any actual evidence, and based on my own research, Matrix seems plenty adequate for my and most people's needs, and certainly far more private and secure than Revolt. I'm not against implementing the Signal protocol into Revolt (or any other platform), as it is absolutely a secure protocol, but a) that's only if it can perform the functions required, which I question if it could in this case, and b) that security can only be assured if the platform, and the Signal protocol's implementation, were fully open, which doesn't appear to be the case with Revolt. I'm honestly confused by people that on the one hand criticize (without offering any specifics or sources) the Matrix protocol, yet on the other use a program that isn't even fully open-source and has even less auditing than Matrix. You guys criticize Matrix because of flaws found--despite the fact that any software, be it Signal, linux, Android, or even DARPA's, has had vulnerabilities that have been discovered with enough testing--yet at least Matrix is prominent enough to have security researchers and others actually look for flaws (which are found and fixed), whereas the only reason Revolt hasn't had flaws found is likely because it doesn't receive the same attention. And before you make another (wrong) assumption, I'm not anti-Revolt, pro-Matrix, or anything else (except anti-Discord); I just want a truly secure and private messaging platform that works well. IME, Signal is secure but not usable and not all that private, Revolt is not secure, private, or usable, and Matrix is at least moderately secure and private and mostly usable, certainly more so than the others. |
|
Just figured I'd jump in and say that E2EE is still in a very early stage and minimal discussion has taken place regarding it. In the event that it's added there would be an RFC first to discuss implementation. Revolt also doesn't plan to use any existing protocols as it would require changes to the way the platform is used on a much more general level. Revolt doesn't intend to be a Signal or Element client and from all I've seen of the protocols they aren't hugely flexible in the way Revolt would need. Also, I can see this discussion potentially taking a hostile turn, so remember to act respectfully. |
To clarify, Element isn't the protocol, it's a UI/application that uses the Matrix protocol. As for Revolt using its own vs an existing one, that's highly recommended against, and it would make Revolt considerably less secure, at least in theory. So any comparison between Signal, Matrix, and whatever Revolt were to use would place Revolt far below the other two, so anyone, here and elsewhere, that considers Matrix unsecure would have to consider Revolt even less secure. And yes, I'm aware Matrix is in the same boat, having rolled their own, but it's been around longer, is much more widespread/popular, and therefore has been scrutinized much more. I want to be clear: I'm not saying Matrix is as secure as Signal or that Signal shouldn't be used. I'm simply saying that, from everything I've read, Matrix is far from unsecure, and certainly not to the degree to refer to it as "broken" or "next to plaintext" or "rich in vulnerabilities." It shouldn't be discounted based on security, especially if it can fulfill the role more than the Signal protocol can. If that's not the case, I'd love to know, because I use it. But I see no evidence of that, from my own research or from anything offered by those criticizing it, apparently baselessly, here. I just take issue with people turning others away from something that's perfectly adequate for most users' needs, especially when they then turn around and support a project that's even worse. That just really comes off as a personal grievance against the former or false support for the latter, and that's not helping people looking for something to use. So back to this comment, if Revolt won't use either, regardless of which is "better," that makes the argument and choices simpler, as it's then a choice between a longstanding, proven, heavily audited, but limited usability protocol (Signal), a longstanding, mostly proven, moderately audited, more usable protocol (Matrix), and a new, unproven, unaudited protocol of unknown usability created by people that, AFAICT, have zero encryption knowledge (I could be wrong, and I don't mean that as a slam, just stating things as I see them, and the fact someone involved in Revolt doesn't seem to know the difference between Element and Matrix reinforces that). That, to me, makes Revolt potentially fine as a pure Discord replacement, where privacy doesn't matter, but for standard chat/calls/etc, where it does, it makes it a no-go, which leaves Matrix or Signal. And frankly, IMO, it would be better in multiple respects to just not bother with E2EE in that case, and spend the resources on making it a better client for the intended purpose, instead of wasting those resources creating a potentially subpar implementation that is not in the main scope of the project and only serves to offer a false sense of security to users. But really, I don't even care if Revolt uses Signal, Matrix, rolls its own, or doesn't do it at all, because Matrix works fine for me, is secure (enough), and is fully open-source. My main concern was people proclaiming Matrix as broken, and I just wanted to know, since I use it, if that was true, and I've seen no evidence offered that it is, which then concerns me because that suggests people are making false statements and misleading others. If I'm wrong, fine. All I ask is for proof, because I truly want to know if those statements are factual. |
|
I'm aware Element is a client. Merely a slip up, my apologies. |
No worries, easily mixed up, just wanted to keep things clear. |
Think what you want I maintain the fact that any other encryption method is better for revolt than matrix one |
|
@insertish Important nit while implementing MLS: force the group key tree of each group to have leaf nodes per-user. And then have each user have per-device key distribution tree, with the master key of the per-user tree equalling the leaf key of the user from the group tree. That way, you would not leak one's devices. |
|
@DeclanChidlow are you suggesting Revolt roll their own encryption protocol? I would strongly advise against that as we can have another Matrix-esque type of situation. Encryption is very difficult to get right and so rolling your own is just creating more problems for yourself. I am not suggesting in becoming another Signal client, you can use the Signal protocol without just being a Signal client. For example WhatsApp implements it as well as Google for their Google Messages which was previously Allo and Microsoft for Skype. |
need to write out requirements here
TODO: write an RFC (https://github.com/revoltchat/rfcs)
MVP List:
OMEMO-style secret chatsOpenMLS instead?Additional Requirements:
The text was updated successfully, but these errors were encountered: