Yes, if you're looking for alternatives to Signal, you should totally use a solution that hasn't rolled out end-to-end encryption by default[0]. /s
...and that only two clients have implemented so far, out of 50ish that they list on their website.
[0] https://matrix.org/docs/guides/faq.html#what-is-the-status-o...
For all the hate it gets, it does only have mode of communication: End-to-end encrypted, for your contact (as people's addresses are pubkeys) and with forward secrecy.
Most "secure" IM systems fail this basic test. When proper end-to-end encryption is optional, guess what happens.
The whole forward secrecy seems to be unresolved still. They have session keys,but other than that there is no rekeying.
And then we have the whole issue with it relying on supernodes for much of its functionality (offline messages, mobile phone client rs) which leads to it having a subset of the issues many have with signal.
Citation needed.
>Well. I'd rather not have anyone suggest tox.
I'm repeating myself, but for all the hate it gets, I'm unable to come up with a better suggestion than Tox. There's always some kind of flaw: Centralized, no forward secrecy, end to end encryption optional, no way to verify contacts and so on.
The fact is we mostly know what kind of attacks are possible on signal. We know metadata is a potential problem. We know what kind of tradeoffs we get with a centralised architecture. We know how that works and how to mitigate some things. Openwhispersystems have been clear about what Signal provides and what it does not provide (even the wording around disappearing messages is well chosen not to confuse people ).
With tox there is a lot we don't know. Are the supernodes an attack vector? Why aren't the devs clear about using a less distributed architecture for mobile clients? Why don't they provide proper forward secrecy yet they claim to do so? There might be lots of strange properties of doing crypto distributed.
I would not recommend it for secure communication until the amount of unknowns is smaller. It is really that simple.
So your citation for sticking to their old ways is pointing to some old example? That's not what I was looking for.
>Why aren't the devs clear about using a less distributed architecture for mobile clients?
Because it's not a priority to them; Or to me, for that matter. (I don't IM on the phone)
>I would not recommend it for secure communication until the amount of unknowns is smaller.
I don't see how the likes of Signal or the popular Telegram are any better in that regard. Also, adding more features (your phone suggestion) wouldn't help.
Tox has not had this amount of attention and it is written by people who seemed to sincerely believe that using nacl/libsodium made tox safe. If that is not a huge red flag, then I don't know what is.
Telegram is not encrypted by default and when it is it uses a weird protocol, which people warned about from the beginning. The devs were cocky even after a probably unintentional backdoor was found that would have let the server mitm every encrypted communication.
The difference between these three for secure communication is huge.
So basically, argument from authority. No Good.
This is pretty bad, but so is having had your private key compromised in the first place. It should be fixed next time they do a flag day.
Other than that, and the rekeying issue (keys are only renewed when the client is closed. They should be on a period of time, to make forward secrecy really effective), nothing else bad was found.
Notice that, for a couple years now, effort has gone into polishing (toktok) toxcore and documenting things, rather than else (eg: adding fancy features). That's a good thing.
Tox might be understaffed and progressing slowly, but there's nothing fundamentally bad about it. They got a bunch of important things (really distributed, DHT, public keys as addresses, temporal keys for forward secrecy, always end to end encrypted) right. I'm not aware of any other project that got this much right, unfortunately.
If only if Tox got more attention, it'd gain developers, donations, and the possibility of getting a proper audit done.
However, I strongly disagree with the author that Matrix should be recommended as a secure communication platform until E2E is stable (and, from what I understand about your project, you'll enable it by default as soon as you consider it stable enough).
Also, since writing this list yesterday, another client has got E2E running: Seaglass (a native Cocoa macOS client): https://neilalexander.eu/seaglass/
Yes, we had one Synapse server running on a resource-constrained machine that sometimes "fell behind" the rest of the network. I believe that is what had caused such issues. Still, the fact things easily break with server load or network issues means there is something faulty about the protocol. Resilience and reliability are no less important than security.
Meanwhile, the performance of the matrix.org server has definitely improved massively over the last few weeks. We hit a performance ceiling from May through mid July, but since July 19th or so we've finally got CPU headroom back again thanks to stuff like https://twitter.com/matrixdotorg/status/1019957885026144257 and https://twitter.com/matrixdotorg/status/1022095383978233856.
Also, Matrix enables end-to-end encryption by default on clients that support it.
It's one thing not to trust Signal. It's another to recommend alternatives that are far worse.
People have other lives, most often online discussions go way past their due date (I actually like the fact that HN doesn't give you a notification when somebody replies to your comment).
It was a good discussion though, the placebo effect is fascinating.
Let's compare it to F-Droid: He isn't saying that Signal should be distributed via F-Droid by default, just that there should be the option. So the article doesn't seem to say that the defaults are what matter.
If you get the time, please give it a proper whirl. With the recent open-sourcing of their server and proper E2EE by default[2] (but abstracted away from the "regular user"), it's shaping up to be a really solid application. As far as I'm aware they use the same double-ratchet protocol as Signal, but you don't need your cellphone number to register (a big thing for some people - myself included).
1. https://news.ycombinator.com/item?id=16655743
2. https://wire-docs.wire.com/download/Wire+Security+Whitepaper...
Synapse, the reference server, can handle rooms, and force encryption on the rooms.
p2p is client side. Riot, as reference client, is the one that takes care of this, and, if I get everything right, it is on by default.