I see they don't want to review more apps but I'd like to see someone's take on Wire, which seems to have all the things people like about Signal (axolotl-based protocol, open-source, modern) without the things people don't (closed platforms only, weird vibes).
I’ve used Wire for quite sometime before (when Signal didn’t have desktop message sync). I’ve even recommended it here.
It was after a year or so of usage that I realized that Wire does not provide any way to export or save chats outside of its application (it has a backup option to backup from and restore back to Wire). Wire also seems to store images on its servers and those images won’t be available if you save a backup and restore from it. The backup formats are platform/OS specific. Losing images but having just text alone was a big loss for me.
For all practical purposes from a basic end user’s point of view, Wire can be considered as proprietary and closed as Instagram or FB Messenger.
Session’s decision to remove forward secrecy is another big eyebrow-raiser. Signal is widely praised for its double ratchet precisely because it limits the damage if a key is compromised. Session’s lack of PFS means that if your private key is ever exposed (or derived), all your past and future messages are fair game. For a messenger that aspires to anonymity or strong privacy guarantees, this is a major trade-off. I haven’t seen a convincing argument as to why the onion-routed approach can’t coexist with a forward-secure key ratchet.
Where you get into trouble with PFS is if you want to use the same identity on multiple devices, not when you want to use a relay/mix network. If all your devices can't communicate in a timely way and mutually agree on state, their ratchets get out of sync... and you can't guarantee that timely communication. For a lot of users, it's probably reasonable to drop forward secrecy to get multi-device support, and I believe that's Session's main reason for doing it.
What I don't understand is why we have people who are so worried about forward secrecy, which protects you in relatively unusual circumstances, but not worried about traffic analysis, which is always a huge issue.
From my point of view, this guy (or anybody) loses a ton of credibility when he says you shouldn't use a decentralized protocol, even with poorly quantified (but nonzero) resistance against traffic analysis, because it lacks PFS... and then turns around and suggests instead using Signal, which has exactly zero resistance against traffic analysis. For most real use cases, the traffic analysis is a vastly more important concern. I tend to think this is an example of how cryptographers get themselves into trouble by worrying about relative arcana, while declaring major practical attacks "out of scope".
I could probably turn that into an NSA conspiracy theory at least as credible as the one in the blog post, although in fact I don't think there are any NSA conspiracies in play on any side here.
Sounds like the Session people should clean up their code and enlarge their random seeds, though.
I have to respect the PoC, this parallel Pollard's rho is really cool! It's a good reminder that a hash isn't a perfect barrier separating the outputs from the inputs, if the inputs are sufficiently bad!
The fact that this is a valid way to do a Pollard's rho:
public function iterate(string $publicKey): array
{
$sk = $this->uniformToBiased($publicKey);
$pk = sodium_crypto_scalarmult_ristretto255_base(
sodium_crypto_generichash($sk)
);
return [$sk, $pk];
}
... is probably not something most people would have thought of. You don't want to solve the DLP, just a fancy birthday attack to get a collision. Lovely stuff.
I see they don't want to review more apps but I'd like to see someone's take on Wire, which seems to have all the things people like about Signal (axolotl-based protocol, open-source, modern) without the things people don't (closed platforms only, weird vibes).
I’ve used Wire for quite sometime before (when Signal didn’t have desktop message sync). I’ve even recommended it here.
It was after a year or so of usage that I realized that Wire does not provide any way to export or save chats outside of its application (it has a backup option to backup from and restore back to Wire). Wire also seems to store images on its servers and those images won’t be available if you save a backup and restore from it. The backup formats are platform/OS specific. Losing images but having just text alone was a big loss for me.
For all practical purposes from a basic end user’s point of view, Wire can be considered as proprietary and closed as Instagram or FB Messenger.
They seem committed to adopting MLS, which is a net-positive.
https://docs.wire.com/how-to/install/mls.html
https://www.rfc-editor.org/rfc/rfc9420.html
Session’s decision to remove forward secrecy is another big eyebrow-raiser. Signal is widely praised for its double ratchet precisely because it limits the damage if a key is compromised. Session’s lack of PFS means that if your private key is ever exposed (or derived), all your past and future messages are fair game. For a messenger that aspires to anonymity or strong privacy guarantees, this is a major trade-off. I haven’t seen a convincing argument as to why the onion-routed approach can’t coexist with a forward-secure key ratchet.
Where you get into trouble with PFS is if you want to use the same identity on multiple devices, not when you want to use a relay/mix network. If all your devices can't communicate in a timely way and mutually agree on state, their ratchets get out of sync... and you can't guarantee that timely communication. For a lot of users, it's probably reasonable to drop forward secrecy to get multi-device support, and I believe that's Session's main reason for doing it.
What I don't understand is why we have people who are so worried about forward secrecy, which protects you in relatively unusual circumstances, but not worried about traffic analysis, which is always a huge issue.
From my point of view, this guy (or anybody) loses a ton of credibility when he says you shouldn't use a decentralized protocol, even with poorly quantified (but nonzero) resistance against traffic analysis, because it lacks PFS... and then turns around and suggests instead using Signal, which has exactly zero resistance against traffic analysis. For most real use cases, the traffic analysis is a vastly more important concern. I tend to think this is an example of how cryptographers get themselves into trouble by worrying about relative arcana, while declaring major practical attacks "out of scope".
I could probably turn that into an NSA conspiracy theory at least as credible as the one in the blog post, although in fact I don't think there are any NSA conspiracies in play on any side here.
Sounds like the Session people should clean up their code and enlarge their random seeds, though.
HN comments on the first blog post:
https://news.ycombinator.com/item?id=42707409
I think delta chat, https://delta.chat/, looks promising.
I have to respect the PoC, this parallel Pollard's rho is really cool! It's a good reminder that a hash isn't a perfect barrier separating the outputs from the inputs, if the inputs are sufficiently bad!
The fact that this is a valid way to do a Pollard's rho:
... is probably not something most people would have thought of. You don't want to solve the DLP, just a fancy birthday attack to get a collision. Lovely stuff.[dead]