Security issues?

[bohwaz]

Code of conduct

• I have read and agree to adhere to the Code of Conduct

Self-training on how to write a bug report

• I have learned how to write a bug report

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

Hi there are some security issues raised here:
https://soatok.blog/2025/01/14/dont-use-session-signal-fork/

I haven't seen any other way to get these to the developers.

Expected Behavior

Steps To Reproduce

Desktop Version

Anything else?

[KeeJef]

We've written up a full response here. In short, no these are not security issues. All of the "flaws" presented by the researcher are either plainly incorrect or misunderstandings of Session code or cryptography.

[soatok]

We've written up a full response here. In short, no these are not security issues. All of the "flaws" presented by the researcher are either plainly incorrect or misunderstandings of Session code or cryptography.

EXTREMELY LOUD INCORRECT BUZZER

https://soatok.blog/2025/01/20/session-round-2/

[KeeJef]

We've written up a full response here. In short, no these are not security issues. All of the "flaws" presented by the researcher are either plainly incorrect or misunderstandings of Session code or cryptography.

EXTREMELY LOUD INCORRECT BUZZER

https://soatok.blog/2025/01/20/session-round-2/

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.

[gnrlus]

Hi,

I haven't thoroughly read the original poster's claims or all the details in Session's full response. Despite this, here are some important thoughts.

I'm aware there are common misconceptions about cryptography in general and specific algorithms. It's really easy to fail to visualize the sheer scale of numbers involved, perhaps as much as it is for a platform to use a weak algorithm and go unnoticed.

From my research on algorithms in past years I trust this one. And it's easy to misinterpret code. I hope the code will contain as much commenting as possible to prevent misinterpretation.

However, and maybe this should be its own issue, though the title of this issue is "Security issues?", a very generalized title--but what good is all this security if I can't even obtain the signature to verify my app download?

Your instructions for obtaining the signatures, which seemed to work before, per https://github.com/oxen-io/session-desktop/tree/v$SESSION_VERSION/signatures.asc does not work. The signatures.asc file does not exist.

Today I tried:

SESSION_VERSION=1.14.3
export SESSION_VERSION=1.14.3 # latest version as of today
wget https://github.com/oxen-io/session-desktop/releases/download/v$SESSION_VERSION/signatures.asc

The link resolves to https://github.com/oxen-io/session-desktop/releases/download/v1.14.3/signatures.asc which results in an a 404 error using wget and also in my browser, naturally.

It appears you're not doing your diligence by furnishing the signature, which for an organization selling us on security should be alarming. Thus I'd like to sound my own buzzer because this is pretty much offensive. Are you supplying your signatures some other way? Please update your instructions with the correct method or otherwise tell us if you're not going to furnish signatures. For now I don't want to update my app! Why does it have to be like this? If I've missed something I truly apologize, but this worked before and now it doesn't, and it should never be this hard to verify the download and this should never have to be a Github issue for this.

Thanks,
gnrlus

[KeeJef]

Hi @gnrlus

There have been some changes in the release process, as signing has been handed to the STF https://session.foundation/ , signatures are still present on each release but the file name has changed from signatures.asc to signature.asc you can see the file in the extended asset list here https://github.com/oxen-io/session-desktop/releases/tag/v1.14.3

Additionally the main repository for Session has been moved here https://github.com/session-foundation/session-desktop, which is where you can find the most up to date Session Desktop version.

We will update our release signature checking guide to reflect the new changes, every release has been signed throughout the handover