Don’t Use Session (Signal Fork)

It is worth noting that the fact that Session has deliberately weakened their cryptography a lot isn't itself a new finding. The fact that they went away with forward secrecy and reduced the security of the protocol from 256-bit to 128-bit were pointed out by many at least already one and a half year ago, as that is when I heard about it and confirmed it.

Their onion network implementation was also lacking very basic security functions, and shouldn't be thought to be secure. Not to mention that the company behind Session ran most of the onion nodes themselves, at least back then, effectively compromising any anonymity onion routing otherwise would have given.

Session was widely believed to be a scam at best, intentionally backdoored at worst. Either way, not to be used by anyone who needs privacy.

This blog is still interesting though, as they claim parts of the cryptography is actually reduced all the way to 64-bit security, that simply isn't secure. And they also claim the onion layer actually effectively have no encryption at all, thus there effectively never were any onion network as part of Session. That is, Session never provided any anonymity at all. At least assuming I correctly understood the blog post, and the implications.

But I am not surprised.

It will be interesting to see how they deal with these disclosures, and whether we get confirmation that those are actually true too. Because they refused to fix their onion network and heavily defended using 128-bit security and no forward secrecy one and a half year ago, without any valid reason.

But whatever turns out to be the truth here, it is good to remind everyone to stay far away from Session. If one want anonymity, Element or SimpleX over VPN or Tor are far better options, none of them has intentionally weakened their cryptography, nor advertised to have security features they don't. They are not free of issues of course, but Session is entirely broken, seemingly on purpose.

Session has published a response:
https://getsession.org/blog/a-response-to-recent-claims-about-sessions-security-architecture

They again confirm that they have intentionally reduced the security from 256-bit to 128-bit, and intentionally removed perfect forward secrecy. What is new to me is that the reason for reducing the security is to make the seed phrases shorter and easier to remember, that is, user convenience. About perfect forward secrecy they just say the same as before, it is not suitable for the decentralized onion network layer, so they decided to remove it. In both cases, they reduced security compared to the Signal protocol for seemingly convenience reasons.

They claim the security actually is 128-bit and not 64-bit as claimed by the security expert. I do not understand any of the technical details discussed by either party, but according to the rule of thumb I have been taught, elliptic curve cryptography provides half the security in bits compared to the size of the key used. So to have 128-bit security one should have a 256-bit key, that is, a key with 256-bits of entropy, not 128-bits of entropy as Session is doing. I guess an actual cryptography expert have to rule whether what Session is doing is actually secure, but I wished I would have got a better explanation from them why they choose to have 128-bits of entropy other than that "it makes the seed phrase shorter and easier to remember".

They also claim the security expert misread the code about onion network layer not providing any effective encryption at all. There are two methods called encrypt(), one taking the key as a ByteArray, the other taking the key as a String. The encryption using ECDH supplies the key as a String, according to Session. After reading their code, I agree, the security expert has read the wrong encrypt() method. What I can see, the EC public keys used in both code paths pointed out by the security expert are of the type String, always. And the encrypt() that takes a String seem to do ECDH session key derivation in the standard way, including with a simplified HKDF-like step. So it looks correctly implemented to me. One can maybe still argue they shouldn't have two encrypt() methods where one take a ByteArray and the other a String, since neither ByteArray nor String are very hard types. They should either had separate method names, or more clearly defined types such as types named something like SymmetricKey or ECPublicKey, to avoid all risk of the wrong encrypt() method being selected.

In short, Session developers are rejecting all claims of new not-previously-known vulnerabilities or weaknesses in the protocol, but confirm all the previously known weaknesses, that is, only 128-bit security and no forward secrecy, and again say they won't fix that and that it is intentional. They insist the protocol is secure up to 128-bits of security, which if true absolutely is adequate today. But they admit they have deviated from security standards in multiple ways.

N1b Session doesn't require a phone number and doesn't consolidate everything of AWS servers. Winner: Session, even with slightly weaker encryption. Also having accounts recoverable by seed phrase offers some portability and safety with upgrading or changing devices.

angela Session doesn't require a phone number and doesn't consolidate everything of AWS servers. Winner: Session, even with slightly weaker encryption.

K8y Maybe sessions 128 is good enough...

That is the question here I think. If it indeed is 128 bit security like Session claims, it would be secure enough, even if it is a downgrade compared to Signal protocol. However, if it is 64 bit security like the security researcher claimed, and my teacher in cryptography told us as a rule of thumb, then it is not secure enough, as 64 bit security is trivial to break for anyone with a decent computer. Which we can assume all state actors and other possible enemies have.

K8y If a city builds a 50 meter high wall surrounding it, then another builds theirs 65 meters high does it really mean the first city is subverting its security?

This analogy doesn't hold. When we say it is 64 bit security, we mean it takes 2⁶⁴ effort to break the security. If we say 128 bit security, we mean it takes 2¹²⁸ effort to break the security. That is 128-bit security is 20,000,000,000,000,000,000 times harder to break. Hopefully then you understand why those bits of security really matters. In your analogy, it would be a wall that is that many times taller.

K8y However are there any experts here that can see things from Sessions point of view? Like play Devil's advocate...

We would need an actual cryptographic expert to state an opinion about this, and explain why. It is very rare to come across someone that actually understands cryptography to the degree where they can design, analyze and break the security of cryptographic algorithms. And yet, it is a person with that knowledge that must state whether what Session is doing is actually secure. Ideally, Session wouldn't even have deviated from known secure constructs to begin with, but they insist on doing that, and that is what makes everyone so anxious or outright skeptical.

K8y Do you agree session is better at wiping metadata than signal?

Hard to tell. Wiping metadata requires that the nodes that keep the metadata agrees to wipe it, and it is not clear that is likelier to happen in Session where anyone (including attackers) can run nodes, as opposed to Signal where all nodes are run by a single (hopefully trusted) company. Ideally, one wouldn't even collect metadata to begin with. Both Session and Signal does try to minimize the amount of metadata they collect. I don't now exactly what Signal is doing, so I cannot really compare Session and Signal in this regard, but we can say for certain that either collect far less metadata than eg Matrix is doing, but far more than what SimpleX is doing. We can also say that Signal does collect one piece of metadata, phone numbers, that for many would be very concerning and ruin any anonymity towards the chat provider. Here Matrix, and especially Session and SimpleX are better.

Assuming Session is actually secure that is, which is doubtful.

ryrona So because part of the 128-bit key is based on non-random filler, the critic is saying it's equivalent to 64-bit and the Session response it isn't. And you're saying 64-bit is easy to crack with brute force. It's interesting.

This is a question that should have a definite mathematical answer because it's so specific.

The problem is that the math is so complex that I don't know who to trust. My instinct is that non-random filler would not be trivial to remove from the 128-bit information. Even if that knowledge reduced the calculations needed, I doubt it would remove it so much as to make it equivalent to brute-force breaking 64-bit encryption. Since that seems so illogical to me (because a mathematical transformation like that wouldn't be easy to undo) then I don't think the critic is right and probably the response is not right either because that assumption could probably reduce brute-force average time, but I'm just guessing.

More real cryptographic experts would need to offer opinions to convince me.