Help users in Iran reconnect to Signal

But yes you are correct it looks like they're justifying ditching PFS by saying "if someone has your keys you're screwed anyway."

However they're not just stripping away security outright, it's more that they're betting on onion routing to cover the user instead - no one who is sniffing traffic on your WiFi network will be able to get your keys because the traffic is routed through the onion network, therefore the only way anyone would get those keys is by pwning your entire device or having physical access to it while it's decrypted which, as they note, is endgame no matter what messenger you use.

I don't necessarily think this is smart as it's best to not put all your eggs in one basket especially where security is concerned. But given all traffic goes between 5-7 nodes [1] the scope for someone without remote or physical access to your device to get your keys is extremely limited assuming their onion network is as secure as they claim.

As for deniability, they sign the message with the long-term keypair, but once the message is validated this signature is wiped. So again it pretty much comes down to relying on their onion routing to ensure this signature isn't intercepted in transit.

Finally I think it's relevant Session is really designed for a different use case than Signal - since your ID is not connected to any personal identifiers, you can wipe it whenever you want and get a new ID that has zero cryptographic connection to the old one. So while there's no ratcheting of keys, the intention isn't really for someone to stick with the same account for years like it is for Signal where your account uses your phone number as an identifier.

I'll wait for the results of the audit, if they come out and say Session is fundamentally flawed I'll happily concede. I have zero ties to this project aside from finding it useful for particular use cases. My prediction is the initial audit will find some potential vulns as they roll out more of the Session Protocol simply because it's a new fork. Probably why they're getting the audit done now. That's the responsible move when forking a crypto protocol it seems to me.

I maintain that for people who want a messenger that knows as little about them as possible, doesn't rely on a personal identifier, and connects to an onion router reliably (by comparison, using Tor on mobile is... not a good experience) it's at very least an interesting project to watch even if it still needs time to mature.

[1] https://getsession.org/session-protocol-technical-informatio...

I don't get the prejudice some have against blockchains either. It's not even like this is Keybase where they shoehorned a crypto wallet into the app. They do have a wallet but it's a totally separate application. Session is purely a messenger and nothing else, you'd have no idea a blockchain was involved at any part of the backend if you weren't told about it.

I have played around with Tox and it's a cool project, but it's been in beta since 2014 and is not well optimised for mobile at all. I don't think it'll go very far personally.

[1] https://jami.net/swarm-introducing-a-new-generation-of-group...

https://www.theverge.com/22249391/signal-app-abuse-messaging...

Thanks to olah_1 for this reference

Session has a pretty nice UX though, better than Wickr which has been around longer, although not as refined as Wire. It's pretty much a more barebones Signal without phone numbers as far as pure UX goes. It should follow the system setting for dark mode though. No idea why it doesn't.

> I have to say, I’ve considered the utility of it myself. It seems to me that I’m far, far more likely to have my chats compromised through my chats being stored in plain text on my devices than in a technical scenario that PFS could have prevented. What do you think?

To be honest I agree. It's always good to have layers of security in case there's an exploited vulnerability in one. However, it seems pretty far fetched that someone with the ability to pull off a successful attack to grab your keys in the first place is going to be stopped from grabbing past messages by PFS.

If they've got your keys they've either cracked the layers of encryption that protect them in transit (highly unlikely) or they've pwned your device (much more likely). If they've got remote code execution on your device PFS isn't going to make any difference to anything. As you say, messages stored in plaintext is a far bigger real world risk.

This is why I always have disappearing messages on. That makes me feel safer than PFS. At least then in the worst case scenario past messages simply aren't there in storage.

To put it another way, if I had to choose between disappearing messages and PFS, and I could only have one, I'd choose disappearing messages.

And it does also seem to me less like they're removing security, more like they're relying on a different form of it. They're having to strip PFS to make the protocol work reliably on their onion network. The fact all my traffic goes E2EE through 5-7 nodes, as per the technical description, should provide a strong level of protection against any traffic sniffing threat model assuming their fancy new way of doing onion routing is as secure as they say.

It seems to me that's what it really hinges on. As long as their onion router is actually secure, the E2EE messages are going to be secure in transit.

The biggest risk then would come back to unpatched exploits or 0days in the OS or side channel attacks in Session itself. That's how most attacks on messengers succeed after all, not by complex attacks on the crypto protocol but through side channel attacks in the application or exploits in the underlying OS.