That ticks me off too. I'd rather suggest Tox.

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.

Well. I'd rather not have anyone suggest tox. The whole "we use nacl so we are safe" attitude from a couple of years ago seems to still be around. Good on them for using nacl. A shame they don't seem to realize that you can write bad crypto with it.

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.

>The whole "we use nacl so we are safe" attitude from a couple of years ago seems to still be around.

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.

Regarding the citation, it is just a matter of reading how the core devs reply to potential security issues. Sure, it has gotten better, but it is not too far from the good old https://github.com/irungentoo/toxcore/issues/121

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.

>Sure, it has gotten better, but it is not too far from the good old

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.

Signal is better because people who knows their shit has vetted the design and quite a bit of research on the protocol has been done. We a quite certain of the security properties of the signal protocol.

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.

>Signal is better because people who knows their shit has vetted the design

So basically, argument from authority. No Good.

Then I ask you: as a non-cryptographer who knows enough to understand RSA, how should I verify cryptographic claims? People i find trustworthy claim signal is good, which is further confirmed by studies and third party suits. I know this is an appeal to authority, but nobody can personally verify every claim made to them. I believe I have done due diligence.

It helps that they used NaCl. When cryptographers looked at it, they found an issue: People can impersonate your friends if they get their hands on your private key.

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.

Fwiw, Matrix E2E actually exists in separate codebases in: Riot/Web, Riot/iOS, Riot/Android, nheko, matrix-python-sdk, libpurple (in PR), and shortly in Fractal (thanks to https://gitlab.gnome.org/jhaye/olm-rs etc). So yup, it sucks that it's not turned on by default in private rooms, but we're working away as fast as we can.

I love your project and am really looking forward to replacing a lot of stuff with Matrix-powered chat.

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).

For the record, E2E is currently in libpurple master (only decryption not encryption) and in PR on matrix-python-sdk. Just a slight flip there.

my bad; i thought all the python ones had landed now. in practice the work is done.

Also, since writing this list yesterday, another client has got E2E running: Seaglass (a native Cocoa macOS client): https://neilalexander.eu/seaglass/

Last time I've tried Matrix (this spring) with a group of peers, my E2E rooms were full of random "failed to decrypt" and lots of out-of-band communications "hey, are my messages working for you today?"

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.

That mirrors my experience with the matrix.org homeserver. It has not improved much over all the months.

We've been working away fixing causes of 'unable to decrypt' bugs, to the extent that (as a poweruser) I almost never see them. If you see them, please report them via bug report so we can dig into them.

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.

Author here, this is a fair criticism. Other alternatives (which I have not reviewed in depth) include Tox, Telegram, Wire, and Ring (not an endorsement of any of these). I'm an old curmodgen who just uses IRC+OTR and GPG, though, so I have to depend on others for recommendations.

Also, Matrix enables end-to-end encryption by default on clients that support it.

According to friends in the cryptography space and from a cursory reading of wikipedia, Telegram is a shitshow compared to Signal.

It's one thing not to trust Signal. It's another to recommend alternatives that are far worse.

(Totally unrelated, sorry, but about a month ago you and I had a brief exchange about the placebo effect.[1] I got distracted and missed your last reply and never responded. Sorry about that. It's too late to reply on the original thread, and I don't want to hijack this one, but while looking for an old comment I saw your reply and felt compelled to mention it to you. It was a good exchange IMO and I didn't mean to "ghost" on it.)

[1] https://news.ycombinator.com/item?id=17457085

I appreciate the apology, but I don't feel ghosting on an online conversation should require an apology.

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.

Yeah, I almost let it go but then I figured, what's the harm? It was a good discussion. Well met.

You suggest Telegram over Signal? Now we know you're spreading FUD.

I don't actually endorse any of the alternatives, just listing them. I haven't had time to research them in depth. I have worked with Tox before and I know some of the guys behind it, though, but I think it's dead in the water.

We've banned this account.

Why would you rely on others for recommending those, but not for Signal? Just don't recommend anything then, or don't criticise Signal. What's the point of convincing people to move to worse alternatives?

I personally reviewed Matrix before recommending it on my blog. The other alternatives I listed here are not endorsements.

Then why would you recommend a solution that hasn't even enabled end-to-end encryption by default?

When did I do this?

You recommended Matrix in your blog which, according to the first comment in this thread, is not end-to-end encrypted by default (which you acknowledged in your first response). Why would you recommend that instead of Signal?

Oh, I should have caught that and addressed it in my earlier response. Matrix is end-to-end encrypted by default on clients that support it. The valid criticism is that some clients don't.

Because for some that's not a show-stopper.

In the context of this article, framed as an alternative to Signal, I think it should be.

Why?

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.

But in the article he's saying not to use Signal because he doesn't consider it secure enough, and to consider Matrix as an alternative. His criticism of Signal has nothing to do with defaults, and everything with security.

Let's also not forget XMPP+OMEMO.

I really like Wire, for a large number of reasons - privacy and user experience among them. I've talked about it in the past[1].

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...

I'd say Wire is a good substitute.

Nonsense. You can run your own Matrix server and set whatever defaults you want.

A Matrix server can force E2E on all messages passing it?

Yes, it can - for instance the Matrix servers that the French government runs do this by default already. We haven't exposed this as a config option and pushed it into mainstream Synapse yet because of https://github.com/vector-im/riot-web/issues/6779, but the tweak for doing it is:

https://github.com/matrix-org/synapse/pull/3426/files

Is this true? As far as I know, even in rooms with m.room.encryption, you can still send normal m.room.messages. Or does the config option you're describing automatically setup room PLs such that m.room.message can't be sent?

technically you can still send normal m.room.messages (or anything else), but any spec-compliant client will refuse to do so in a room where m.room.encryption has been enabled.

That looks like a no given the article has a "Create a new secure room" section where you have to explicitly enable encryption for that specific room.

e2e, by nature, is client specific. So Matrix, as a connectivity glue protocol, has nothing to do with it.

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.

Regardless of the truth of your assertions, the article you provided as evidence does not support them. At no point does it demonstrate that a matrix server can force E2E on all communications, that synapse can be configured thus, or that riot can require that configuration.

Or conversations.im? Matrix + riot leaves a heap of meta data about you on the federated server. If that server is compromised, so are you.

Surely Matrix doesn't leave any more metadata than XMPP with MAM enabled (which presumably most XMPPers use these days)?