# 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
**Showing post:** 1 of 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.

---

_[View the full topic](https://discuss.privacyguides.net/t/im-rtc-perfect-forward-secrecy-requirement/11840)._