# IM/RTC: Perfect Forward Secrecy Requirement **URL:** https://discuss.privacyguides.net/t/im-rtc-perfect-forward-secrecy-requirement/11840 **Category:** Site Development **Tags:** completed **Created:** 2023-02-16T16:42:14Z **Posts:** 41 ## Post 1 by @jonah — 2023-02-16T16:42:15Z We’re [currently considering](https://github.com/privacyguides/privacyguides.org/pull/1994) a change to our instant messenger criteria which would require all messengers to support Perfect Forward Secrecy. This would disqualify Session of course, which notoriously removed support for PFS in a crypto change despite initially supporting it while their product was based on Signal’s crypto. Generally speaking, the team is okay with this change. This would also disqualify Matrix. While Megolm theoretically supports PFS, [it is not mandatory](https://gitlab.matrix.org/matrix-org/olm/blob/master/docs/megolm.md#partial-forward-secrecy) and in fact is not used in practice at all, because the option to do so [is not exposed in Element](https://github.com/vector-im/element-web/issues/7101), and would break functionality like key backups: > by default, our use of megolm doesn’t provide perfect forward secrecy. this is by design, so that if you log in on a new device, you can still rescue your encryption keys from other devices and read your history, which is the expected UX. in other words, devices don’t delete megolm keys after they’ve been used to decrypt history (which is why you can back them up and share them with your other devices in order to ensure that all your devices can read your history). […] We’ve always intended to provide PFS semantics as an option for those who need that level of paranoia (at the expense of drastically increasing the number of unable-to-decrypt errors, as keyshare and keybackup mechanisms would no longer be available to mitigate them); […] The way I see it here, we have essentially two choices, because I think the team is in agreement that PFS is important: 1. We can require PFS, and remove Session and Matrix. 2. We can put PFS in our best-case criteria, and clearly delineate between Signal, SimpleX, and Briar, and Matrix and Session, and say that Matrix/Session are only useful for certain use-cases with some limitations, similarly to how we distinguish between providers which use OpenPGP and those that don’t on our email recommendations page: [https://www.privacyguides.org/email/](https://www.privacyguides.org/email/) It is worth noting that like Matrix, Session does fulfill some specific use-cases for people, such as having desktop clients which SimpleX lacks, and so keeping it listed while noting its downsides much more prominently is probably a reasonable move here. --- ## Post 2 by @ph00lt0 — 2023-02-16T16:54:35Z As @matchboxbananasynergy also argued on github Matrix serves (or should serve) a different purpose. It’s more a platform for large rather public rooms IMO much like IRC (people still use this). If this means that Matrix is removed as IM I think that that is a right decision. It doesn’t nearly offer the same standard. I am fine with using Matrix but not for the same things that I would be discussing on Signal. We always have to think what are we protecting from whom. Matrix I personally do not use for sensitive data and I would discourage you from doing so. --- ## Post 3 by @matchboxbananasynergy — 2023-02-16T17:00:03Z While it is true that SimpleX doesn’t currently have a desktop app as far as I’m aware, Briar now has a Windows and Linux desktop app, with macOS supposedly coming eventually. Something being cross-platform is paramount to its usability, as IM is only useful when both participants are being to use it, but I think that it is more important to support projects that put significant effort in doing encryption properly. Session’s jarring decision to remove PFS makes it a non-starter for me. I’ve used it in the past, and along with the aforementioned deficiency, it was also consistently buggy on both Android and desktop (Linux) and I eventually had to give it up. Matrix has its own issues. Along with no PFS and E2EE flaws that still feel weirdly unaddressed and swept under the rug (this could have changed, but that was the impression I got previously), it is also clunky as hell, especially in E2EE rooms. It’s so often bad that it has become a meme at this point. I actively use Matrix, but like @ph00lt0 said, I wouldn’t trust it for sensitive discussions, and I wouldn’t recommend it to someone at all who wasn’t already using it due to all of the reliability issues that plague it. I would be completely fine with seeing Matrix go from the recommendations, personally. --- ## Post 4 by @dngray — 2023-02-16T17:02:59Z > [@matchboxbananasynergy](#): > > Matrix has its own issues. Along with no PFS and E2EE flaws that still feel weirdly unaddressed and swept under the rug (this could have changed, but that was the impression I got previously), it is also clunky as hell, especially in E2EE rooms. It’s so often bad that it has become a meme at this point. I seem to remember one of the FOSDEM presentations touching on that particular point as a motivating reason for doing MLS. --- ## Post 5 by @jonah — 2023-02-16T17:09:23Z I suppose _my_ proposed solution would be to state PFS is a best-case criteria, and restructure the page as follows: - Encrypted Messengers - Signal - SimpleX - Briar - Additional Options - Element - Session With a warning on the second category along the lines of: > These messengers do not utilize [Forward Secrecy](https://en.wikipedia.org/wiki/Forward_secrecy), and while they fulfill certain use-cases that our previous recommendations may not, we do not recommend their use for long-term or sensitive communications. Any key compromise among message recipients would compromise the confidentiality of **all** past communications. I realize this almost brings back “worth mentioning” projects in a sense, but this is actually a change I’ve been meaning to make for a while, because it provides additional nuance to our recommendations that the current flat hierarchy of recommendations lacks. The truth of the matter is that none of these projects are the best at _everything_, and presenting them in a way that makes them seem interchangeable seems harmful. At the end of the day there is no viable replacement for Matrix for the purposes we commonly use Matrix for, which it sounds like everyone agrees with, since everyone in this thread so far actively uses it, so removing Matrix from the site entirely does not make sense to me. --- ## Post 6 by @matchboxbananasynergy — 2023-02-16T17:16:42Z > [@jonah](#): > > At the end of the day there is no viable replacement for Matrix for the purposes we commonly use Matrix for, which it sounds like everyone agrees with, since everyone in this thread so far actively uses it, so removing Matrix from the site entirely does not make sense to me. The way most people use Matrix is for public rooms with no encryption whatsoever. I use Matrix because it is where the groups I want to be a part of are, not because I enjoy the Matrix user experience or think it brings significant benefits, especially when it comes to privacy. To me, it makes a lot of sense for the real time communication page to focus on _private_ methods of doing so. Signal allows for groups, and while they’re not as versatile as Matrix rooms, as mentioned, Matrix has a lot of issues and bugs that can completely brick rooms when they exceed a certain size, which has been seen in practice and has not been fixed at this point, to my knowledge. You can argue that there is no use in privacy when we’re talking about a group as anybody could be leaking messages outside of that group, but at least it provides assurances in cases where all participants of the group keep what’s being said in there confidential. I see no use case for Session when it comes to group chats, and while I see the usefulness in using Matrix for public, unencrypted discussion, it may not necessarily make sense in the real time communication page. --- ## Post 7 by @jonah — 2023-02-16T17:34:28Z Matrix has to provide a level of privacy over its alternatives, which in this case aren’t really Signal and Briar, but are Discord and Slack. Which it absolutely does, so I don’t really follow the argument that it doesn’t merit a mention on [privacyguides.org](http://privacyguides.org) at all. And if it does, then I don’t see how we can fairly remove Session, which supports unlimited-size public groups and pretty much all the other features one would expect from a messenger. I think the anti-Session camp just needs to come up with a better reason to remove them, because personally not liking it isn’t the best argument when plenty of people use Session every day just fine. --- ## Post 8 by @ph00lt0 — 2023-02-16T17:55:45Z > [@jonah](#): > > And if it does, then I don’t see how we can fairly remove Session, which supports unlimited-size public groups and pretty much all the other features one would expect from a messenger. I think the anti-Session camp just needs to come up with a better reason to remove them, because personally not liking it isn’t the best argument when plenty of people use Session every day just fine. I do not think any one has said Matrix deserves no place at all. But I do not see it as an IM in the way we use Signal. Matrix serves a good solution for a short message format much like email. It is actually distributed and easy to run for larger communities. As for session. Session does not support community like features like Matrix does. Therefore cannot be really compared to Matrix. I feel session is more a simple IM. Session however advertises them as being the best IM for privacy, which I simply cannot agree with. Also I have never heard a good argument from them to use a modified protocol without PFS. Their CTO said to me a couple of times they believe they do not need it because their service is distributed. This is a really neglecting mass surveillance of ISPs and the fact that companies behind session that controls this network. PFS is a very essential measure against cryptographic attacks and can prevent a lot of harm as it drastically slows down the capabilities of any adversary. To summarize, PFS should be the standard for an IM, simply because this is good practice. You shouldn’t be using either Matrix or Session for your private conversations. Matrix serves a community, Session doesn’t really. Therefore I can only conclude that there is really no good reason to be using Session. --- ## Post 9 by @jonah — 2023-02-16T18:00:00Z - How does Session not support a community? - How is Matrix not Real-Time Communication? I believe your concerns are addressed in my proposal TBQH, so I don’t know what changes to make here. --- ## Post 10 by @ph00lt0 — 2023-02-16T18:01:22Z - Session does not have moderation like Matrix - Matrix isn’t as secure, i am not saying it doesn’t have these features, just would never use it for this. --- ## Post 11 by @jonah — 2023-02-16T18:04:07Z [session-pysogs/administration.md at 2c8e4f1535bbd2cc676fa46914c691d2332cb41f · oxen-io/session-pysogs · GitHub](https://github.com/oxen-io/session-pysogs/blob/2c8e4f1535bbd2cc676fa46914c691d2332cb41f/administration.md) indicates Session has community moderation. --- ## Post 12 by @ph00lt0 — 2023-02-16T18:05:27Z I am fine with your proposal btw, I just don’t see the purpose of Session I would however still think of a different caption session does have encryption. So we might want to have something like: - Perfect Secure messengers (idk?) - Messengers for community conversations. (idk?) This would also allow to state requirements for what we believe is a good secured messenger. If you think there is a purpose for Session in less sensitive conversations go for it, but I see no reason to list project that are not used much in this way. Just like we could list every offline note taking app on android but I prefer to have just one good one. --- ## Post 13 by @jonah — 2023-02-16T18:09:38Z I don’t like Session either\*, all I’m saying is that there are no compelling reasons that come to my mind to remove Session if Matrix is kept. The goal is to have consistency, if we can’t define criteria that lets us include Matrix and exclude Session then we should not be excluding Session, that’s all I’m saying. If we **can** create criteria that does this though then I’m all ears. \* also my feelings about Session are not really relevant, because many many people **do** like Session. --- ## Post 14 by @matchboxbananasynergy — 2023-02-16T18:11:54Z I think I see the issue here. I would not necessarily remove Matrix from Privacy Guides, but I would perhaps put it in its own page. I’m unsure whether we are all on the same page on whether Matrix should be used for private and encrypted communication or not, but if not, perhaps there should be a page on messengers like SimpleX, Signal and Briar which are IM solutions which provide modern encryption, and another page for as you said Discord and Slack alternatives, in which Matrix, despite its issues, fits. Does that make more sense? By that token, Matrix makes for a pretty good forum for community discussion. In that context, does it have advantages over Session? I believe it does. Do options like SimpleX and Signal have advantages over Session in the context of private conversations? I believe they do. Therefore, it feels like Session is in this weird middle-ground that makes it subpar at multiple things at once. --- ## Post 15 by @ph00lt0 — 2023-02-16T18:11:56Z I get your struggle in this tho and I know someone will not be happy with this discussion already. But why list things if they serve no one in a way that helps them? Matrix is the thing people use for communities ( i wish there was something better) but honestly nobody uses session for this stuff or am I missing out? --- ## Post 16 by @ph00lt0 — 2023-02-16T18:14:19Z Okay so I just checked. I can see 3 public communities in Session: - Lokinet Updates - Oxen Updates - Session Updates I think it proves my point --- ## Post 17 by @jonah — 2023-02-16T18:14:48Z So this was also brought up in our chat, but my question is if we create a new page for community discussions, what would be the reasoning for excluding Session from _that_ page? Because theoretically Session does support community features, including self-hosted group servers specifically for this purpose, i.e. [GitHub - oxen-io/session-pysogs: Python implementation of the Session community server](https://github.com/oxen-io/session-pysogs) > [@ph00lt0](#): > > honestly nobody uses session for this stuff or am I missing out? My understanding is that some people do. > [@matchboxbananasynergy](#): > > I’m unsure whether we are all on the same page on whether Matrix should be used for private and encrypted communication or not I am also not sure, but my perspective is that we are all on the same page that Matrix serves _a purpose_ in this space and should be included somewhere on the site regardless, so I don’t think our opinion on this particular issue actually impacts our overall discussion here. --- ## Post 18 by @ph00lt0 — 2023-02-16T18:17:37Z I mean if people do, fine let’s put in that place, nothing against that. For the category we should clearly state that there are different more secure options for IM I do wonder tho, any public community known? In the app I see none other then their own. --- ## Post 19 by @jonah — 2023-02-16T18:19:10Z > [@ph00lt0](#): > > In the app I see none other then their own. I don’t believe there is a central room directory, community operators would [share their QR codes](https://oxen.gitbook.io/oxen-docs/products-built-on-oxen/session/guides/open-group-setup#6.-join-your-sogs) within their own communities, which would make enumerating the number of public rooms out there difficult. --- ## Post 20 by @matchboxbananasynergy — 2023-02-16T18:20:38Z We can look further whether Session provides the same flexibility as Matrix for communities (I doubt that but I am open to finding out). If that is the case, perhaps Session and Matrix can be on the same page. I don’t know what the real-time communication page should be renamed to, but it should operate under the assumption that this page is for people looking to communicate with privacy and proper encryption with all of its bells and whistles. The new page that can include Matrix/Element and/or Session etc. would be for platforms that we recommend for non-sensitive communication. --- ## Post 21 by @ph00lt0 — 2023-02-16T18:24:07Z sums it up well --- ## Post 22 by @jonah — 2023-02-16T18:25:09Z Okay, but that brings me to my other point, which is that I don’t see how that is any different than what the changes in my proposal convey on a practical level. --- ## Post 23 by @ph00lt0 — 2023-02-16T18:26:33Z I think we have come to conclusion that the proposal makes sense :slight_smile: --- ## Post 24 by @matchboxbananasynergy — 2023-02-16T18:28:26Z Them being on a separate page delineates the differences between them (recommending for private communication vs recommended for casual/non-critical communication). Them being on a separate page also entitles them to having a different set of criteria which are much better suited to their strengths, rather than shoehorning in tools meant for public/non-critical discussions in a category whose criteria is the same as messengers meant for private communication. --- ## Post 25 by @ph00lt0 — 2023-02-16T18:30:32Z ah i was not here yet, but this does make sense tbf. --- ## Post 26 by @jonah — 2023-02-16T18:32:10Z The reason these were combined in the first place is because the distinctions between these products are very muddied. Most of them support public and private group chats, and they all support DMs. Does that mean we don’t recommend Signal groups? Does that mean there are no scenarios where Matrix DMs make sense? etc. My POV is that these tools all accomplish basically more or less the same function, which is why they are grouped together, and really the only issue we have here is varying levels of security, which is fixed by simply _informing people about those varying levels of security._ After we do that, we leave the determination between feature-sets as an exercise to the reader. --- ## Post 27 by @ph00lt0 — 2023-02-16T18:34:25Z okay actually this convinced me. I am with you @jonah. It does makes sense, I am actually in quite some communities on signal too. But I also see why people wouldn’t want that. --- ## Post 28 by @jonah — 2023-02-16T18:34:33Z What about if a Matrix/Discord competitor comes up that has equivalent security to Signal? --- ## Post 29 by @matchboxbananasynergy — 2023-02-16T18:36:09Z That’s fair. Good talk. :smile: --- ## Post 30 by @jonah — 2023-02-16T18:59:44Z > > > Rendered alternative proposal to #1994 from discussion at https://discuss.privac…yguides.net/t/im-rtc-perfect-forward-secrecy-requirement/11840/5?u=jonah > > > > - [x] Please check this box to confirm you have disclosed any relevant conflicts of interest in your post. > - [x] Please check this box to confirm your agreement to grant Privacy Guides a perpetual, worldwide, non-exclusive, transferable, royalty-free, irrevocable license with the right to sublicense such rights through multiple tiers of sublicensees, to reproduce, modify, display, perform, relicense, and distribute your contribution as part of our project. > - [x] Please check this box to confirm you are the sole author of this work, or that any additional authors will also reply to this PR on GitHub confirming their agreement to these terms. > > > Closes #1994 --- ## Post 31 by @Niek-de-Wilde — 2023-02-16T19:16:36Z The proposal seems reasonable with me. --- ## Post 32 by @jonah — 2023-02-16T21:45:38Z Status: In Progress → Done > **[Downrank messengers without PFS (#1999) ·...](https://github.com/privacyguides/privacyguides.org/commit/242894c291aa014e95536bf27963dd353d9c9bab)** > > Co-Authored-By: mfwmyfacewhen <94880365+mfwmyfacewhen@users.noreply.github.com> --- ## Post 33 by @Fossforus — 2023-05-28T11:14:28Z Sorry to resurrect this one but there are some point re PFS that haven’t been touched on. I was doing some digging on Session [see here](https://getsession.org/session-protocol-technical-information/) and they raised some great points about the PFS limitations of their protocol, which I think warrants a technical debate. It seems like in session’s new protocol the PFS limitations are very niche and quite extreme circumstances would be required for the security limitations to come into effect. If you believe their technical info on their protocol then you could describe it as APFS the A stands for almost :wink: To paraphrase them: PFS becomes relevant when we assume the attacker has full device access, and thus the long term key, which is stored only on the device, is compromised. In which case: 1. “Reading **all previous messages** in the conversation by pulling plaintext message history directly from the device.” - “Neither the Session Protocol nor the Signal protocol can prevent an attacker from this” - Conservatively IMO over 90% of users keep their history and do not actively use self destructing messages or clear their history as they like to go back and reference messages. Even in the privacy community, how many dramas do we see filled with screenshots of chat history? Lots. See the recent GrapheneOS drama. What about those remaining hardcore privacy nerds who use self destructing messages only? Surely Session should cater for them too for it to be recommended… 1. “If the attacker has full device access and the user has disappearing messages turned on” - “both the Session Protocol and the Signal protocol prevent the attacker from reading any previous messages” Ohh okay then, so why isn’t it PFS? 1. “If an attacker has both full device access **and targeted network scraping capability** , and the user has disappearing messages turned on” - “the Signal protocol can protect users’ previous messages from being read, while the Session Protocol will not.” They then go on to say the following which I won’t go into as this post is already way too long: “There are ways for Session to limit the scope of this attack by limiting the data which an attacker can scrape, which will be discussed later” Lastly before signing off let’s talk about how likely a targetted network attack is. To quote @keejef from Reddit who put it quite well. "Service Nodes do have the ability to subvert the protocol and hold onto messages past their regular 4 day TTL. So if we had a network attacker in Session who was roughly 10-20% of the network that passively stored all messages, and that same network attacker hacked into a users device and stole their long term keys, and the user had enabled disappearing messages then the attacker would be able to decrypt all past messages, even though there was a lack of message history on the device Any broad network attack of this size would cost well into the multi millions of dollars (Staking 15,000 Oxen for hundreds of nodes) + the cost of specifically targeting the user to steal their devices long term keys." So assuming you believe the above, we’ve established 1. The flaws in Sessions Forward Secrecy are quite niche 2. The likelihood of exploiting the flaws are quite low Now if you factor in the advantages of Session such as anonymity at sign-up with no identifying info or metadata tied to your account, that the server code is open source and the fact that it’s decentralised with the benefits that brings then: **Does this niche use case really outweigh the other benefits that Session brings mentioned above? If you’re dealing with this sophisticated of an adversary, is Signal really ahead?** --- ## Post 34 by @ph00lt0 — 2023-05-29T08:09:33Z This has all previously discussed extensively. I am not going to repeat the agreements. It’s just insanely weird that session removed PFS while they could have easily kept it. There arguments for it sorry not sorry do not make any sense. They control the network. --- ## Post 36 by @Fossforus — 2023-05-29T11:25:36Z Got a source for those ‘extensive discussions’? I just checked the Github for the old repo (apparently naming it gets my post flagged…), the new one for privacyguides, a few reviewers of private messengers I like and reddit but I’m yet to find anyone actually break this down. They make the argument that with their limited sized team, reworking forward secrecy allowed them to introduce new functionality by streamlining the code. Haven’t done a pre and post comparison of the source code so can’t confirm they’re not making it up. --- ## Post 38 by @ph00lt0 — 2023-05-29T11:45:46Z I can’t see what exactly got flagged and why but just look at the privacytools repo archive and the github repo of this, even on this form. Its really a passed station man. The giving up PFS for functionality is just BS. I can’t see any reason why this would be true and what would be the problem here. It just sounds like a lack of understanding of cryptography and how to apply it. --- ## Post 39 by @jonah — 2023-10-15T06:19:26Z --- ## Post 40 by @redoomed1 — 2025-05-10T13:15:08Z --- ## Post 41 by @redoomed1 — 2025-05-10T13:17:25Z > [@List Element under Social Networks + IM/RTC Page Changes](https://discuss.privacyguides.net/t/list-element-under-social-networks-im-rtc-page-changes/26077/1): > > we downranked instant messengers without PFS [like Element], to account for these social-networking-like group functionalities we wanted to recommend. If we categorize these as social networks we can describe the risks/benefits of each more clearly. With this change already reflected on the website, we can now take the first approach: > [@jonah](#): > > We can require PFS, and remove Session > > > List of changes proposed in this PR: > > - With the [migration of Element from th…e Real-Time Communication page to the Social Networks page](https://github.com/privacyguides/privacyguides.org/pull/3013) as discussed in [FORUM-26077](https://discuss.privacyguides.net/t/list-element-under-social-networks-im-rtc-page-changes/26077), move the criterion for Perfect Forward Secrecy support from best-case to minimum requirement > - Relevant discussion: https://discuss.privacyguides.net/t/im-rtc-perfect-forward-secrecy-requirement/11840 > - Remove Session as a result of the new criteria > - Relevant discussion: https://discuss.privacyguides.net/t/remove-session-from-instant-messaging/18852 > - Remove "Additional Options" and "Encrypted Messengers" headers since there is currently no need for this distinction anymore > - Adjust header levels as a result of the above change > - Format criteria for RTC recommendations using these writing guidelines: https://discuss.privacyguides.net/t/writing-style/27321#p-92745-use-must-for-requirements-11 > - Embed link to paper on future secrecy and post-compromise security in the second footnote, which is also cited in Signal audit in 2016 --- ## Post 42 by @redoomed1 — 2025-05-10T13:18:47Z --- ## Post 43 by @redoomed1 — 2025-05-10T13:18:58Z Done → In Progress --- ## Post 44 by @redoomed1 — 2025-05-17T00:27:27Z In Progress → Done --- ## Post 45 by @redoomed1 — 2025-05-17T00:27:32Z