6
Is Session really secure and private?
(self.session)
A sublemmy for discussing session, getsession.org, an opensource decentralized chat application.
I have read it at https://www.securemessagingapps.com
Oxen people argument: "under typical circumstances, the only way long term keys can be compromised is through full physical device access — in which case an attacker could simply pull the already-decrypted messages from the local database. As is often said in the infosec community, physical access is total access" source: https://getsession.org/blog/session-protocol-explained
They are also saying "We will be looking at making it easier to rotate accounts as a whole" source: https://github.com/oxen-io/session-desktop/issues/2338
That website has a lot of things wrong, and provides no citations for most of its claims: it just says "Yes" or "No" about most things.
SimpleX says they don't log IP addresses, and their claim is at least as credible as anyone else's. I suspect the securemessagingapps web page gave them a "No" in that column because SimpleX is refreshingly honest in their threat model and privacy policy, and thus mentions that even though they don't log IPs their hosting provider (or the hosting provider of other SimpleX servers - you don't have to use one of theirs) could be. They currently recommend using Tor to mitigate this problem.
Most chat apps allow you to delete old messages, both on an individual message basis and automatically after some period of time. Does Session not?
Who would say that, except someone trying to excuse their protocol's lack of forward secrecy?
There is no reason why physical access to a device should mean total access to messages that were deleted previously; all serious secure messaging protocols today use forward secrecy to limit the impact of device compromise.
Furthermore, most modern (eg, designed in the last decade or so) protocols also provide post-compromise security (aka "backward secrecy", "future secrecy", or "self-healing") to introduce new entropy into their ratchets such that when a device is temporarily compromised (as is actually very often the case in real-world attacks on mobile operating systems) the key material which an attacker can exfiltrate doesn't allow them to decrypt future messages which are sent later after the device is uncompromised (eg, rebooted).