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 . 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.