[Feature Request] Implement PFS, Increase Entropy in Key Generation and Improve Moderation Capacity in Session for SOGS misuse

[qdhj]

Let's take one more look at the arguably the strongest Session Messenger critisizing article out there — key points are short key & lack of PFS.

Now, I know the PFS is an often again-rasied question, but hear me out, I want to say something new! It doesn't matter, if lack of PFS is really a big problem — what matters is that it's a huge turn-away for many people, who care about privacy (even if they're wrong & not pro enough not to understand that PFS doesn't matter!) Actually it's so big, competitors, like SimpleXChat, use it to compare themselves to Session; so big, that it's used as "Session's main weakness". So, "PFS is not that important" agenda doesn't seem to work anymore — if we want to save the project ecomically, after time it became rather actually worthy, beneficial to implement PFS, even if it requires more work. The article above even proposes a simple idea, how to do it.

It’s actually really easy to include PFS with Session’s design, should they actually care about post-compromise security for their users. Tunnel SignedPreKeys over the same channel you use to send encrypted messages, then keep Signal’s excellent ratcheting protocol in place. If you need a higher layer that doesn’t utilize it because of some onerous technical requirements, then just wrap your forward-insecure protocol around a forward-secure protocol.

(The other way to work around this problem is to create a good, source-based video, instead random interviews here and there and twitter publications, about why lack of PFS is okay, how it lacks in any cryptocurrency and people don't scream about bitcoin / monero / PGP is made by government, etc—but once again, this is just pushing away the problem, and today it might be rather worthy to spend time on implementing PFS somewhat, somehow, than continuing to struggle. Also, all three have longer bit keys to make it worth using them without fear.)

Talking about too short 128-bit key, it is just... true. We gotta make our protocol impossible to hack, not very hard to hack, if we want Session to give safety to political activists and other governments' enemies, not only pedophiles — specially while we don't have PFS.

Now, read the hyperlink to the pedophiles page, it's also worth mentioning.

I have written 108 bugreports/handy feature requests for Session, trying to contribute, since I really like this app. I hope to get attention here, since this might be the most important issue I've written. I am afraid that Session is drowning, and will drown, if we don't try to save it (among else by discussing the criticism).

[KeeJef]

I generally agree with you that there is an issue with the "perceived" security of Session, even though this perception doesn't always map to reality. The cryptographic security provided by PFS is not well understood by most privacy enthusiasts, and it has become a checkbox feature; if a messaging app doesn't have PFS, it's often discounted by potential users. It has been a challenge to communicate effectively about PFS, as the topic quickly gets technical and hard to follow, and there are strong preconceived notions about what PFS provides that are difficult to challenge.

I will say Session contributors have been speaking about PFS a lot recently and are looking into ways Session might be able to achieve a notion of PFS without the technical hurdles it creates, especially considering Session's use of a decentralized network and multi-device syncing. Session's tooling has improved significantly since PFS was removed, especially with the introduction of libsession. libsession—a shared library now implemented across all platforms—allows Session developers to implement complex protocols more consistently across all platforms, which reduces cross-platform bugs. However, significant challenges remain. A PFS implementation would likely require every linked device to maintain its own key pair that cannot be synced between devices. This creates problems around key rotation: if one device rotates its keys while other linked devices are offline for a significant period of time, those devices might encrypt messages for a non-existent key, resulting in lost messages. This is a challenge that other messengers using multi device still encounter. But I do think there could be a happy medium here, and this is something Session contributors are actively exploring.

Regarding Session's current use of 128 bits of entropy in keys, it does seem to be perceived as a weakness, even though, in practice, the security difference between key seeded with 128-bits of entropy and key seeded with 256-bit key is minimal, given current computational power and algorithms available to attackers (brute-forcing a 128-bit key is well beyond the reach of today's attackers). But given the perception, I do think it would be good either to offer the option to use 128 bits or 256 bits of entropy for key generation or to switch to 256 bits of entropy by default. Historically, Session has used less entropy to create smaller recovery password (13 words instead of 24 or 25), which makes recovery passwords easier to write down and save. Before any change is made, we also need to think about backward compatibility and any long-term changes we might want to make to Session's key generation, especially to ensure future compatibility with cryptocurrency wallets. For instance, transitioning from the current wordlist to a BIP-39 compatible wordlist could allow users to import and export their Session accounts to cryptocurrency wallets.

As for the SOGS moderation issues, this is indeed a challenge. It's important to recognize that any tool providing security and privacy can be misused, and this has been true for every such tool throughout history. For example, both Signal and Tor are widely used by human rights activists and journalists but also used by criminals. Much thought has gone into designing Session to encourage positive use while minimizing misuse. For example, Session limits the ability to discover and connect to communities within the app, addressing a common vector for abuse in other messaging apps. Additionally, SOGS servers must be run with publicly discoverable IP addresses by community operators, making it easier for third parties to identify and take action against SOGS servers being misused by contacting the ISP or hosting provider to shut them down. Nonetheless, I believe there are ways Session can be further strengthened to address such issues while preserving the privacy and censorship resistance of the network. This has been a topic of discussion among Session contributors since the project's inception and will continue to evolve over time.

That said, I do think that Session's current user base is overwhelmingly using the app for the right reasons, but it is not without its challenges, challenges like Signal and other private messaging apps have faced before.

[qdhj]

Keepin' my answer short,

The cryptographic security provided by PFS is not well understood by most privacy enthusiasts

Yes, of course. As said, most of those who scream about session being spoiled by lack of it forget that bitcoin, monero also lack pfs. And yet, there's an important problem for session due to lack of PFS: if the keys are stolen, you don't know you're compromised. Nor do you with crypto, but there's not much bad actor can do with your crypto but steal it -- so, if your crypto is gone, you create a new wallet. Now, if your key is stolen, you can write years of dialogues without knowing they're read and saved by the bad actor. This specially goes with the shorter key problem.

A PFS implementation would likely require...

Notable, that there are very clever ideas described in the issues session on how to implement PFS in a decentralized way. (Can't say if they're good or bad, too dumb for that -- yet they seem to be clever.)

Brute-forcing a 128-bit key is well beyond the reach of today's attackers

True, yet this specially goes with the lack of PFS. If there is no way to check, if I am being watched, I want to at least make it an almost-impossible case. But, once again, this is a smaller problem -- and pfs (or other way to check if one's been compomised) & 64 bit might be better option than no pfs & 256 bit.

Session has used less entropy to create smaller recovery password (13 words instead of 24 or 25), which makes recovery passwords easier to write down and save.

Limiting passwords (i.e. dropping security) in length "so it's easier to save them" seems weird. Mnemonic phrases are usually written down only once in many years, so it's not a big deal even if it had 48 words.

We also need to think about backward compatibility

Sure

It's important to recognize that any tool providing security and privacy can be misused, and this has been true for every such tool throughout history

Sure, yet I believe we can be creative to make our tool harder to misuse. I don't believe in the argument "we'll let it be, since they also let it be" -- we can do better! Many ideas were already described here: eg. Default Deny, Role-based Access Control, Auto-CSAM detection already made by hloth, and etc.

Additionally, SOGS servers must be run with publicly discoverable IP addresses by community operators, making it easier for third parties to identify and take action against SOGS servers being misused by contacting the ISP or hosting provider to shut them down

Sure, I've taken +10 CSAM servs like this. Though, wasn't the dev team implementing lokinet for sogs exactly to make this impossible?

Thanks for your time.

[keybreak]

@qdhj

Auto-CSAM detection

With all respect, let's put morality aside for a moment, and think purely in technical terms for a second.

1. If we want freedom and privacy above all - both onion networks and messengers, by nature will and (unfortunately) as a side effect should have all kinds of criminal activity and other things that you or i don't like.
   If it doesn't - it's a huge red flag, and definitely controlled and censored, there's no 2 ways about it.

2. Any auto-whatever AI detection can and will be abused by nature, as it is basically 3rd party monitoring / censorship MitM attack, that definitely can and will arbitrary change criteria of detection and action, which effectively will nullify encryption and freedom of communication. See for example Apple / Google / Microsoft device-based content scanning.

   Basically it's already happening on those operating systems, like it or not, and anything outside of Linux and GrapheneOS is not safe, including Session, as encryption of communication doesn't mean shit anymore, since all messages are read and analyzed on devices BEFORE encryption. So to be clear, observers of 5-eyes extremely likely (unless those criminals have stellar OPSEC, which is nearly impossible) already have full access to read and act on those CSAM chats, and the only reason they're not acting on it - political will.

3. Criminal stuff like CSAM and drugs in the internet doesn't mean anything on it's own, as both require real-life activities, where police absolutely by all means can and should act, and they verifiably really doesn't in way too many cases. Not to mention authorities around the world are knee deep in those activities themselves (i'm sure you've heard about Epstein, as well as horrific relevant systemic cases in UK and Germany, some of which are still ongoing), so i would assume that should be priority, as those are known crimes.

---

Philosophically speaking, a world where free will doesn't exist (meaning ability to create both good and evil) - is slavery, by robots for robots.

In my view, our duty as free human beings, is to cultivate incentives to do good and moral things, and oppose evil directly, help / force solving known IRL crimes, rather than trying to cure symptoms of "freedom problem" online.