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 called Session. My answer then is the same thing I’ll say today:
Don’t use Session.
You must log in or # to comment.
Cliff notes: end to end encryption is borked.
So borked in fact that the author’s fursona face-palmed in response.
I weren’t even aware it was a Signal fork! What kept me away was their heavy integration of the Oxen crypto token (now apparently replaced with their own “Session token” instead). Anything that deep into web3 is a red flag to me, but the security flaws discussed in the above blog post look white hot.
the Oxen crypto token
Oxen is the company behind Session, for anybody unfamiliar. They were a crypto company that made (well, cloned) a messaging app to promote this token.
And Oxen itself was a clone of Monero.
Strong agree. Session is not security focused it’s marketing focused. Last I checked they still use central servers for file uploads.
Nice writeup as always. I always wondered about Session but it seems like they have the same “I rolled my own” crypto nonsense as Telegram has; and we all know how bad that one actually is as it’s not correctly implemented at all; even if the underlying protocol is otherwise good.
Use simplex.
That’s nice you’re mentioning SimpleX but its design is way too complicated compared to alternatives (e.g. Signal) that no one will use it.
Even as a tech-savvy person, I was shocked that I have to scan a QR code to chat. I can’t imagine how it feels for non-tech people.
As a result, who will you actually chat with? 🙂
It would be nice to read the basic points of your statement, then if someone wants to go in detail, there’s the link to your article.
it’s not my article.
Ops. However a small TL;DR would be useful instead of just copying/pasting links.
TL;DR from oss-security:
At a glance, what I found is the following:
- Session only uses 128 bits of entropy for Ed25519 keys. This means their ECDLP is at most 64 bits, which is pretty reasonably in the realm of possibility for nation state attackers to exploit.
- Session has an Ed25519 verification algorithm that verifies a signature for a message against a public key provided by the message. This is amateur hour.
- Session uses an X25519 public key as the symmetric key for AES-GCM as part of their encryption for onion routing.
Additional gripes about their source code were also included in the blog post.
Jesus Christ, get fucked
Thanks for the notice!
Regular Signal for lyfe.
