Multiple problematic cryprographic issues

[JavaDerg]

Hi!

I've come across this article recently outlining some problematic cryptographic issues in Session.
https://soatok.blog/2025/01/14/dont-use-session-signal-fork/

As none of these issues (as far as I could find) have been addressed in the issues on this repository, I decided to post this link here.

I am not the author of the blog post!

[SWORDIntel]

Well you've kicked a can of worms haven't you? I will say quite bluntly that I have heard and it is my firm belief that these backdoors are intentional by a nation state. Probably shouldn't be saying this but fuck it you only live once.

This is my understanding that from a friend's research into making custom firmware for his router based on the LokiNet that he discovered the back doors in that and somehow that transferred over to Session both by the same government

I have heard corroborating data from other sources.

[JavaDerg]

Well you've kicked a can of worms haven't you? I will say quite bluntly that I have heard and it is my firm belief that these backdoors are intentional by a nation state. Probably shouldn't be saying this but fuck it you only live once.

This is my understanding that from a friend's research into making custom firmware for his router based on the LokiNet that he discovered the back doors in that and somehow that transferred over to Session both by the same government

I have heard corroborating data from other sources.

I kinda doubt that, backdoor are typically crafted with more care and less obvious.
The issue with reduced Ed25519 security to me feels more like a lack of understanding than anything.

[SWORDIntel]

Its possible both are true,i've also heard from a reliable source that session fully complies with this nation state's subpeonas every time

Having looked through it it seems like it is a mix of simply very sloppy work with a sprinkle of weaponized malicious incompetence , theres not really any excuse for such poor implenentations and so many of them

I will be eager to see a reply ,even if i am ENTIRELY somehow off base(im not) the fact of the matter is any semi competent threat actor just with the information in the article can fully compromise session.

Im going to stick with the very safe totally not turbofedded telegram :)

[KeeJef]

I've written up a full response to the security researchers blog here , the author is either plainly incorrect or misleading on all of the raised security issues.

As for the other claims from @SWORDIntel , that Session has intentionally introduced backdoors on behalf of nation states, this is false, if you have evidence of such a backdoor i would encourage you to make a public disclosure and warn people about it. I certainly don't want people using Session if its backdoored. Further to this, Session devs and contributors don't have any privileged access to the Session network, which means if a government asks for information via a subpoena, there isn't any information to give. This is inline with every transparency report published by the OPTF and STF.

[SWORDIntel]

Proof, I mean, if I did, I still wouldn't be posting it, you know, because it's not something that needs to get out there. I just... If there was a back door, which maybe there should be, then I would just like it to be hidden better.

I mean I'm sorry if I came off hostile, you know how this world is. I mean at the end of the day criminals do need to do what they need to do sometimes and we have to just bear with it but also they need to think they're safe and I mean it's a complicated balance. So you're saying categorically that the session is absolutely safe and secure with no way for any government body to access it whether they want it to or not?

I do not know or believe it's intentional backdoors. I do believe it's likely backdoors that are present that are being taken advantage of. So you really are sure that every single issue brought up in this article is just a non-starter and comes from a poor understanding of their code.

[JavaDerg]

I was already planing to write a response, but Soatok cut me short on that.
https://soatok.blog/2025/01/20/session-round-2/

TL;DR

• As asked by the response by session, Soatok has come forward with a working POC in regard to the reduced security on the Ed25519 keys. Due to the lack of forward security, this also means that there is no trivial way of mitigation, and being able to crack one of the keys would be catastrophic.
• (As I also was planing to point out) Soatok pointed out the misleading code in AESGCM.kt, which by function overloading expects a byte array for symmetric encryption, or a string as public key for X25519 wrapping. This is not great, one would expect “AESGCM” to, well, do AES-GCM, differentiation of both key kinds by type may be reasonable if they were properly encapsulated, but using a byte array vs. a string is not that.
  After skimming over the code base in libsession the crypto code seems to be scattered all over the place, at least I could not find a general place to review crypto related code.

Soatok also pointed out a lot more things, so please read the article, but these are IMO the most pressing points.

[KeeJef]

We have now updated our original blog post with a response to the PoC provided by the security researcher here https://getsession.org/blog/a-response-to-recent-claims-about-sessions-security-architecture . In short

• The approach implemented in the PoC by the security researcher does not achieve any reduction in security for individual Session accounts. If attacking a single account, the proposed approach offers no advantage versus a traditional brute force attack against a 128 bit key, something which is impossible given current computing technology.
• The security researchers PoC for a multi-target attack performs worse than a common benchmark algorithm for this type of attack, called a linear search.
• When calculating a worst-case scenario for a multi-target attack on Session using linear search, we find that on average it would cost tens of thousands of times more power than the entire planet consumes in one year to compromize even a single random Session account out of 4 Billion + accounts—even when the parameters for such an attack are set very favorably for the attacker.
• Given this Session Accounts remain secure against both specific and targeted attacks and multi-target or batch attacks.

[link2xt]

I have tested the PoC even before your blog post and have a much less noisy confirmation that PoC is indistinguishable from bruteforce: https://github.com/link2xt/short-seeds-poc
The graphs for the number of steps taken are exactly the same, but PoC fails >80% of the time and appears to be fast because of this.

In any case, I just wanted to add that 128-bit of security is generally considered good for classic cryptography, but for PQC you need to aim for 256-bit because of Grover's algorithm. When Session switches to PQC public keys and AES-256 (which seems to be the solution used by all PQC systems like Signal and OpenPGP PQC draft) for symmetric keys, it might be a good time to increase the seed size to at least 256 bits, and no need to spend time changing anything now if you will have to redo everything for PQC anyway at some point.

[link2xt]

So maybe for the next steps use SecureRandom everywhere in a consistent way, maybe refactor the code around AES-GCM and close the issue?