Source URL: https://soatok.blog/2025/01/20/session-round-2/
Source: Hacker News
Title: Don’t use Session – Round 2
Feedly Summary: Comments
AI Summary and Description: Yes
**Short Summary with Insight**: The text is a critical analysis of the security and cryptography protocol design of the Session messaging application compared to its peers. It discusses weaknesses in Session’s cryptographic practices, such as inadequate seed sizes, lack of forward secrecy, and potential attack vectors, particularly concerning the Ed25519 signature scheme. The analysis underscores the importance of robust cryptographic standards and protocol design, making it particularly relevant for professionals concerned with software security, information security, and protocols in secure communications.
**Detailed Description**:
The blog post examines various vulnerabilities and design flaws in the Session messaging app’s use of cryptography, especially in comparison with other secure messaging protocols, like Signal. Below are the key points discussed:
– **Pollard’s Rho Method**:
– The author initially claimed an attack using Pollard’s rho method on Session’s design, stirring discussions about its validity.
– The post aims to clarify the application of the Pollard’s rho method in attacking cryptographic primitives and the resulting confusion regarding terminology and method distinctions.
– **Key Generation and Seed Sizes**:
– There’s a critical focus on Session’s cryptographic key generation, noting the use of 128-bit seeds instead of the more secure 256-bit seeds recommended by libsodium.
– The author presents proof-of-concept (PoC) scripts that demonstrate the feasibility of collision attacks on these shorter seeds, emphasizing that while secure against casual adversaries, these practices leave the application vulnerable to capable entities.
– **Lack of Forward Secrecy**:
– A significant point raised is Session’s removal of forward secrecy, which is vital for protecting historical messages even if current keys are compromised.
– The author argues that this design decision greatly increases the potential blast radius of any successful attacks.
– **Protocol Design Flaws**:
– The blog critiques the way Session handles cryptographic protocols, emphasizing that attacking an app’s reliance on user-provided data (like public keys) for verification processes creates exploitable weaknesses.
– The author laments Session’s failure to minimize the variants in their state machines, which can lead to unforeseen exploits.
– **Response to Session’s Counterarguments**:
– The author critiques Session’s rebuttals to their earlier blog post, highlighting misunderstandings and misinterpretations from both parties regarding the security implications of their code.
– Specific claims from Session about their cryptographic design and key generation practices are dissected, reinforcing the contention that they have, in fact, rolled their own cryptography despite claiming to use libsodium.
– **Overall Recommendations**:
– The author strongly recommends against using Session, favoring other applications like Signal which adhere to more rigorous cryptography standards and practices.
– While the author acknowledges interest in the development of better alternatives, they stress the importance of robust security measures and evaluations by third-party auditing firms in assessing secure communication platforms.
The discussion holds practical implications for security professionals, emphasizing continuous scrutiny in cryptographic design and the necessity for established standards in software security implementations. The detailed analysis of Session’s code and protocol decisions outlines potential vulnerabilities that can serve as a guide for improving the security posture of similar applications.