# Don’t Use Session (Signal Fork) [Article] **URL:** https://discuss.privacyguides.net/t/don-t-use-session-signal-fork-article/24006 **Category:** General **Tags:** software, article **Created:** 2025-01-15T09:53:20Z **Posts:** 42 ## Post 1 by @steve_donald34 — 2025-01-15T09:53:20Z I read this today. But I’m not expert. I need your comments. > **[Don’t Use Session (Signal Fork) - Dhole Moments](https://soatok.blog/2025/01/14/dont-use-session-signal-fork/)** > > Last year, I outlined the specific requirements that an app needs to have in order for me to consider it a Signal competitor. Afterwards, I had several people ask me what I think of a Signal fork c… --- ## Post 3 by @Pragmatic — 2025-01-15T17:52:30Z Question: why did Session take the decision to remove forward secrecy, and for what purpose? --- ## Post 4 by @soatok — 2025-01-15T18:44:18Z They claim [in a 2020 blog post](https://web.archive.org/web/20241225131654/https://getsession.org/session-protocol-explained) that their motivation is: > The simple fact of the matter is that Session provides protections against these types of threats in other ways — through fully anonymous account creation, onion routing, and metadata minimisation, for example. These protections will prove as effective, or more so, in many real-world scenarios within Session’s scope and threat model. They think this is a replacement for KCI security. I disagree. --- ## Post 5 by @fria — 2025-01-15T18:50:47Z It’s wild too because SimpleX Chat has their private routing now so it’s clearly possible to have all the features session offers and more while keeping PFS. --- ## Post 6 by @Niek-de-Wilde — 2025-01-15T18:56:13Z How do you think this slipped past their audit? --- ## Post 8 by @anon48875053 — 2025-01-15T19:26:58Z Like I said in the topic regarding 1Password and open source, audits aren’t a silver bullet. --- ## Post 9 by @soatok — 2025-01-15T19:33:07Z I can only speculate, as I don’t recognize any of the names on the Quarkslab audit from 2021. The blog post announcing it also mentions [the review of all 3 apps was timeboxed to 10 days](https://blog.quarkslab.com/audit-of-session-secure-messaging-application.html). The timeline in the audit report PDF made me think it was a much longer project than that. Neither of the “R&D Engineer” employees listed on the report have done much publicly since 2021. I don’t see any cryptographers on the roster, either. All in all, I can speculate about all the ways this could have slipped past. But I wasn’t there, so who knows? They did identify the weak entropy issue, on each app platform, but decided it wasn’t a big issue. Now, having been in a vaguely similar boat earlier in my career, what I think happened (grain of salt, please; I wasn’t actually there) is something shaped vaguely like: - Engineer: “Hey, we found this!” - Oxen team: “Is it exploitable?” - Engineer: “Hmm, I dunno. Maybe?” - Oxen team: “Well, we deliberately do this so the recovery phrases are only 13 words, not 25. It should be fine.” - Engineer: “Yeah, I can’t argue with that. Maybe if I had time to poke around more and write a PoC…” - Manager: “We don’t have time budgeted for this kind of research. Let’s move on.” At least, that’s what I imagine happened when I read their statements in the finding. --- ## Post 10 by @soatok — 2025-01-15T19:34:54Z Correct. You might be interested to hear, I’ve also looked at 1Password before (as well as LastPass). I wrote about my experiences [here](https://soatok.blog/2023/01/21/how-you-respond-to-security-researchers-says-everything-about-you/). Takeaway: Based on how both vendors responded to my reports, I would absolutely trust 1Password over LastPass. I can’t speak to Dashlane, Bitwarden, etc. of course. --- ## Post 11 by @fria — 2025-01-15T19:42:14Z That tracks lol --- ## Post 12 by @Niek-de-Wilde — 2025-01-15T21:28:20Z I guess this is another example of how audits are not the security fairy dust people make them out to be. In any case thanks for the info on this , its highly informative and I will be discussing with the team on how to move forward. We will most likely be delisting Session. As a side note, folks with proper knowledge about cryptography are very hard to come by, would you mind if I reached out to you in the future if I were to have a question about certain platforms or services regarding their cryptography implementation? I highly respect the work that you do. --- ## Post 13 by @soatok — 2025-01-15T21:48:40Z Thanks for the kind words. I’d be happy to share my opinions as needed. --- ## Post 14 by @fria — 2025-01-15T22:14:06Z > [@Niek-de-Wilde](#): > > We will most likely be delisting Session. That would be ideal yeah. At this point I don’t think it offers anything you can’t get elsewhere anyway. --- ## Post 15 by @Redroyach — 2025-01-15T22:47:00Z A lot if this cryptography talk goes above my head but if the issues are as serious as they seem it makes me loose all the hope I had for lokinet, if they don’t have good cryptography for their main product they will surely screw up something on their onion router. --- ## Post 16 by @anon47447111 — 2025-01-17T02:25:30Z Something something, threat model. The author notes in the article that some of the criticisms are contested and it appears fairly theoretical. If someone can’t or won’t use Signal, I’d think Session is still far preferable to [some alternatives.](https://old.reddit.com/r/signal/comments/1i2rb2r/just_moved_to_signal_from_insta_what_are_some/m7h4ce0/) To me “Don’t use” might be hyperbolic. If you didn’t have a phone number, certainly preferable to use Session over some other alternatives. --- ## Post 17 by @Surreal — 2025-01-17T03:40:54Z Thanks for introducing your blog @soatok I’ve bookmarked it. I agree, we need more cryptographers on here to weigh in with their expert opinions and cryptanalysis. :smiley: I’ve been a big fan of [Bruce Schneier](https://www.schneier.com/), going back to his Blowfish and Twofish algorithms (the latter was even a finalist for NIST’s AES contest, despite Rijndael winning out in the end). Cryptography is one of those subjects where I tend to defer to trusted subject matter experts (like Bruce). The complex algebra is beyond me! :laughing: --- ## Post 18 by @soatok — 2025-01-17T04:21:12Z One of the first cryptography books I ever read (sheerly due to availability in my library) was his book describing the TwoFish block cipher. At the time (2010), I didn’t understand a lick of the advanced math, but I really wanted to. I sometimes quote Schneier, but I’ve since come to know a lot of cryptographers and they’re mostly excellent people. Unfortunately, there aren’t nearly enough people with expertise in this field in the world, so their time is highly prized. (If anyone is interested in learning, [SalusaSecondus maintains an excellent Getting Started page](https://gotchas.salusa.dev/GettingStarted.html).) --- ## Post 19 by @steve_donald34 — 2025-01-17T11:15:27Z as a result will session be de-list from PG ? :slight_smile: --- ## Post 20 by @faxe — 2025-01-17T11:21:14Z As stated above by a PG team member > [@Niek-de-Wilde](#): > > We will most likely be delisting Session. --- ## Post 21 by @mangomango — 2025-01-17T12:39:32Z Welcome to the community ! I had never seen your blog before and I find it amazing :+1::+1:Nice to read about cryptography in messengers apps, cryptocurrencies and to get to know the furry fandom. --- ## Post 22 by @jsil2077 — 2025-01-17T13:09:25Z A response from the Session team, I guess: > **[Blog - Session Private Messenger](https://getsession.org/blog/a-response-to-recent-claims-about-sessions-security-architecture)** > > View the Session Blogs. | Session is an end-to-end encrypted messenger that removes sensitive metadata collection. --- ## Post 23 by @yes — 2025-01-17T13:20:31Z I’ve read and understood it to some extent (as I’m no expert) and it looks like a good answer. I assume @soatok you’ll write a blog as a response to them, until then I’ll wait for your blog. --- ## Post 24 by @phnx — 2025-01-17T13:28:16Z They still gloss over the removal of PFS which is Soatok’s main reason for already recommending against Session. I’m also not at all qualified to comment of Sessions response but given the lack of PFS I still think Session should be delisted. SimpleX Chat also seems superior in just about every way making Session effectively redundant. * * * Soatok added an edit for the first claim in their [article](https://soatok.blog/2025/01/14/dont-use-session-signal-fork/): > **EDIT (2025-01-16):** In the interest of transparency, you should be aware that the following claim is being questioned by a few cryptography experts. > > To resolve this discussion, I intend to write a proof of concept soon for the kind of attack I _think_ is possible here, but on a much, much smaller scale (since I don’t have the resources of a nation state). I will update this post later with the results of my experiment. > > I’m leaving the rest of the text unchanged so you can see the assertion intact. > > Even if it turns out I’m mistaken about what follows this blue-boxed text, there is no question that Session’s security against batch attacks is severely downgraded from what you’d expect from Ed25519. --- ## Post 25 by @jonah — 2025-01-17T15:45:48Z > [@phnx](#): > > since I don’t have the resources of a nation state I’m curious @soatok what resources specifically do you think would be required to perform this? --- ## Post 26 by @soatok — 2025-01-18T07:38:08Z Absolutely. Their response isn’t 100% incorrect or misleading, but it warrants a correction. But first, a proof-of-concept script needs to be written. I will include it with the blog post I’m writing next. --- ## Post 27 by @soatok — 2025-01-18T07:48:34Z I sorta gave you the answer in the blog post already: The ability to perform 2^64 queries in a reasonable amount of time. Each query consists of, at minimum, a SHA512 hash and a scalar multiplication over an elliptic curve. That scalar multiplication is going to be the expensive part. I can write quick and dirty scripts that perform ~10,000 to ~100,000 scalar multiplications per second on my computer (really, keypair generation). 2^64 is 18,446,744,073,709,551,616. If I tried to do this all on my personal computer, it would take approximately 585,000 calendar years. You can parallelize this pretty well, and write more optimal code than I did locally. WIth the NSA’s resources, you can probably parallelize this effort to 100,000,000 devices in a cluster (this is a Fermi estimate). If each device in the cluster is able to perform 100,000 queries per second, you can perform the attack in ~180,000 seconds (or about 3 days of dedicated compute). That’s performing a batch attack against a 128-bit seed (what Session uses), using Pollard’s Rho to find collisions without requiring storage for 2^64 candidate keypairs on top of all this. My proof-of-concept is going to be much more economical. --- ## Post 30 by @ph00lt0 — 2025-01-18T13:27:45Z Most of these things have been previously dicussed and there were also papers written on the security of session messenger earlier. I would agree there is an issue with the lacking PFS. The arguements for them not needing it are wrong in my opinion. > [@Remove Session from Instant Messaging](https://discuss.privacyguides.net/t/remove-session-from-instant-messaging/18852/28): > > We already do so. Unfortunately it isn’t available anymore as Elon Musk kicked me of Twitter lol but I had lengthy discussions about this all with the CTO of session a few years back. We came to the conclusion of agreeing to disagree that their measurements are to be trusted to be sufficient for lacking forward secrecy. I do not agree that the network (largely controlled by them) removes this need. The fact that they first had forwarded secrecy and then just removed it is beyond me and unaccep… --- ## Post 31 by @soatok — 2025-01-20T08:32:00Z I’ve published my response (and proof-of-concept code) for Session’s blog post: > **[Session Round 2 - Dhole Moments](https://soatok.blog/2025/01/20/session-round-2/)** > > Last week, I wrote a blog post succinctly titled, Don’t Use Session. Two interesting things have happened since I published that blog: A few people expressed uncertainty about what I wrote ab… --- ## Post 32 by @jerm — 2025-01-20T09:43:45Z Thanks for response. > Signal is simply the only private messaging app I’ve looked at to date and haven’t been able to brutally criticize. I try several times a year to see if a new attack strategy I learned will work on their software, because it galls me to not have a notch in my belt for their software. (One of these days, goddammit!) Have you read: [SimpleX blog: SimpleX Chat v5.6 (beta): adding quantum resistance to Signal double ratchet algorithm](https://simplex.chat/blog/20240314-simplex-chat-v5-6-quantum-resistance-signal-double-ratchet-algorithm.html) ? (this now the default in v6 for 1-1 chats btw) > Double ratchet algorithm is used in Signal, Cwtch and SimpleX Chat. But Signal app by allowing to use the same profile on multiple devices compromises the break-in recovery function of Signal algorithm, as explained in [this paper](https://eprint.iacr.org/2021/626.pdf). Because of break-in recovery you cannot use SimpleX Chat profile on more than one device at the same time - the encryption scheme rotates the long term keys, randomly, and keys on another device become useless, as they would become useless for the attacker who stole them. Security always has some costs to the convenience. > - unlike Signal design that only added quantum resistance to the initial key exchange by replacing X3DH key agreement scheme with post-quantum [PQXDH](https://signal.org/docs/specifications/pqxdh/), but did not improve Signal algorithm itself, our design added quantum-resistant key agreements inside double algorithm, making its break-in recovery property also quantum resistant. For the record, their messengers comparison chart in this blog is not very accurate. For example: [https://xcancel.com/SamuelScheit/status/1880734632624406820#m](https://xcancel.com/SamuelScheit/status/1880734632624406820#m) --- ## Post 33 by @soatok — 2025-01-20T09:51:15Z No, I haven’t read that yet. Thanks for sharing. --- ## Post 34 by @jerm — 2025-01-20T13:02:51Z There’s also [Hi Meta, WhatsApp with Integrity? | by Tal Be'ery | Medium](https://medium.com/@TalBeerySec/hi-meta-whatsapp-with-integrity-4d85756dd7c5) (no bloat frontend: [scribe](https://scribe.rip/@TalBeerySec/hi-meta-whatsapp-with-integrity-4d85756dd7c5)), Usenix paper and presentation: [https://www.usenix.org/conference/woot24/presentation/beery](https://www.usenix.org/conference/woot24/presentation/beery), lastly: [https://eprint.iacr.org/2022/1710.pdf](https://eprint.iacr.org/2022/1710.pdf) Another thread where I collected known vulnerabilities: > [@According to Elon Musk, Signal has "known vulnerabilities that are not being addressed"](https://discuss.privacyguides.net/t/according-to-elon-musk-signal-has-known-vulnerabilities-that-are-not-being-addressed/18206/14): > > He obviously lack any proof to back it up, or read some political article about Signal. But it is true that Signal have known vulnerabilities that are not being addressed [https://restoreprivacy.com/signal-for-desktop-is-vulnerable-to-attachments-exposure/](https://restoreprivacy.com/signal-for-desktop-is-vulnerable-to-attachments-exposure/)[https://github.com/signalapp/Signal-Desktop/pull/4381](https://github.com/signalapp/Signal-Desktop/pull/4381) No sandbox on Linux [https://www.ndss-symposium.org/ndss-paper/improving-signals-sealed-sender/](https://www.ndss-symposium.org/ndss-paper/improving-signals-sealed-sender/)[https://arxiv.org/abs/2305.09799](https://arxiv.org/abs/2305.09799) Shit Sealed Sender implementation. Relying on SIM to s… --- ## Post 35 by @Pragmatic — 2025-01-20T13:41:03Z Hmm… so Signal is safe or not and the problems raised in the links are still relevant since 2020? Why is Signal so highly recommended, with so many security problems and disastrous communication? --- ## Post 36 by @Niek-de-Wilde — 2025-01-20T14:20:14Z Because is the golden standard in secure messaging at this moment. --- ## Post 37 by @jonah — 2025-01-20T16:27:55Z I’ll preface this by saying these might be stupidly obvious questions to you, but they are not to me, a non-cryptographer/mathematician. I have to say I think it would’ve been nice if you had published ~~the times it took _you_ to run your proofs of concept, how they relate to each other, and~~ an explanation of how to interpret those results to justify the statement that an attack on 128-bit seeds is plausible to someone with far more resources. My understanding is that what you are doing is proving you can find a 32-bit key in sqrt(2^32) steps, and therefore you are saying you could theoretically find a 128-bit key in sqrt(2^128) (or, 2^64) steps, is that right? If so I guess my main question is the time it takes to run one of these queries compared to the time it takes to generate an SHA-1 hash, which we have plenty of benchmarks for on various GPU hardware. Is it expected to be very similar? Because if it takes much longer to run one of these queries in comparison then I am not sure how well the SHA-1 comparison holds up. edit: I now see your runtimes are published in the readmes for each demo, so nvm. Still have the other questions though. * * * > 1. Instead of Ed25519, I’m using the Ristretto255 group so I don’t have to deal with cofactors in my logic. > 2. Instead of half a SHA512, I’m using BLAKE2b (via libsodium). I also don’t have the background knowledge in cryptography to know whether this makes a practical difference here, so I will just have to take your word that it does not, but I sort of expect Session to bring this up in their response. --- ## Post 38 by @jerm — 2025-01-20T18:32:03Z Idk much about Ristretto255 tbh (this is actually the first time I hear about it) But you can read about why they recommended [BLAKE2b](https://github.com/samuel-lucas6/Cryptography-Guidelines?tab=readme-ov-file#use-in-order-4) and the [libsodium](https://github.com/samuel-lucas6/Cryptography-Guidelines?tab=readme-ov-file#cryptographic-libraries) library here [GitHub - samuel-lucas6/Cryptography-Guidelines: Guidance on implementing cryptography as a developer.](https://github.com/samuel-lucas6/Cryptography-Guidelines) --- ## Post 39 by @sgp — 2025-01-20T23:37:49Z _Disclaimer: this is my summary based on what I discussed with my friend. I’m not a cryptographer._ This is a theoretical attack, not a practical one. The researcher is effectively saying that if: 1. An attacker has possession of a substantial number of Session keys. If Session is like Signal in this way, then each message is a key. A realistic number is about 4 billion or 2^32. Why? Because it’s effectively impossible to break 1 in 2^128, but it’s _within possibility_ to break 2^(128-32) = 2^96. To get down to 2^64, they would need 2^64 keys, or 18 quintillion. 2. An attacker expends significant resources attempting to decrypt the key. Think (very) roughly the current hashing power of the entire Bitcoin network. Basically, some global-scale compute resources. _**After that effort, an attacker would succeed within a reasonable time (e.g. within an average human lifetime, I don’t know the exact time) at decrypting one random key (probably one random message).**_ Is it reasonable to have approximately 4 billion Session keys? Session is a small network and uses (at least partially) decentralized message routing. Even if Session was this widely used, the attacker would need to infect enough Session nodes or run enough of their own nodes to get keys of this magnitude. Then, is it really that practical to expend all this effort to decrypt _ **one random message** _? Clearly Session’s approach is not as good as Signal’s, and to the researcher’s point, you should use Signal if this is a concern for you. However, the issues described in these two blog posts are not practical concerns for the vast majority of threat models. --- ## Post 40 by @KeeJef — 2025-01-24T00:35:06Z Hey guys Just looking at this now, as i wasn’t previously aware that there was a thread here. We have responded to all the claims made by Soatok in a blog post here: [A Response to Recent Claims About Session's Security Architecture - Session Private Messenger](https://getsession.org/blog/a-response-to-recent-claims-about-sessions-security-architecture) . We have updated the blog post to include a response to their PoC Code and updated claims about the security of Session keys. In short, - “Security issue” 1 achieves no reduction in the operations required to crack a single targeted Session account/key, this still requires 2^127 operations on average. A worst case multi-target / batch attack implemented using a linear search achieves an improvement on the ability to break a random key out of a extremely large group of keys, but even with the improvement would still take ~22,000 times the amount of power consumed globally each year to compromise a single random key out of 4 billion + keys, representing no practical impact to Session users. - “Security issue” 2 is not a security issue because of checks which occur on the message and sender before the “In band” signature is validated - “Security issue” 3 is not a security issue because it was based on a misreading of Session code, as confirmed by Soatak - “Gripe” 1 has no impact - “Gripe” 2 has no impact Just to provide some clarity to the points raised by SGP. Session has more than 1 million Monthly active users, each of these users typically has only one Ed25519 key, so the the actual number of Session keys which could be used in a multi-target / batch attack is probably closer to a couple of million keys rather than 4 Billion. But in our worse case scenario we assumed that Session had 4 Billion active users to show that Session remains safe even with extensive growth. Further to this, since there is no central location where these public keys are stored its unclear how an attacker could even gather such a large amount of keys. Regarding the rough calculation that you could leverage a network with the number of operations (hashes) per second that Bitcoin achieves. This was my initial thought too, but the operations used in a multi-target / batch attack are actually EC Base point multiplications rather than hashes, which are many times more computationally expensive than hashes. So the number of operations per second which can be achieved is actually many many times less than the entire Bitcoin network achieves. Privacy guides already places a note on Session regarding the lack of PFS, and considering that none of the issues raised by the security researcher have practical impact, i don’t think there has been any change to the security profile of Session which would justify removal from Privacy Guides. Session offers a unique set of properties not achieved by other messaging applications. No phone number sign up, Onion routing by default, and a use of a decentralized network, while having highly usable cross platform clients which maintain synchronization. Happy to provide any more context if needed. --- ## Post 41 by @sgp — 2025-01-24T04:31:51Z @KeeJef thank you for the detailed update to the blog post, especially the review of the PoC code. I tried to write a paragraph about how the PoC didn’t document failures, but I didn’t know how to word it very well. Your post helps clear things up there. Regarding forward secrecy, was the main reason for not including it complexity, efficiency, or something else? --- ## Post 42 by @soatok — 2025-01-24T07:41:08Z > **[Session Round 2 - Dhole Moments](https://soatok.blog/2025/01/20/session-round-2/#update-2025-01-24)** > > Last week, I wrote a blog post succinctly titled, Don’t Use Session. Two interesting things have happened since I published that blog: A few people expressed uncertainty about what I wrote ab… I feel that addendum there is the only response Session deserves, given their present conduct.