
Cross-signing and end-to-end encryption by default - thanksforfish
https://matrix.org/blog/2020/05/06/cross-signing-and-end-to-end-encryption-by-default-is-here
======
qertoip
Both are asynchronous messengers.

Signal: + protects metadata + protects the content (e2e encryption) - is not
anonymous - is not resilient against regulations

Matrix: - does not protect metadata + protects the content (e2e encryption) +
is anonymous + is maybe, potentially resilient against regulations (federated,
not centralized architecture)

~~~
Arathorn
You could argue that Matrix does protect metadata if you run your own server -
and in extremis, one way of running your own server and protect metadata is to
go P2P and embed it into your client (which is one thing we're currently
working on).

That said, there are some other pretty big differences between Matrix &
Signal; the biggest one is probably that Matrix is an open standard and open
network, encouraging 3rd party clients, servers, bridges, bots etc -
optimising both for freedom/liberty as well as encryption. Signal optimises
for privacy at all costs and doesn't allow 3rd party clients or services. See
[https://matrix.org/blog/2020/01/02/on-privacy-versus-
freedom](https://matrix.org/blog/2020/01/02/on-privacy-versus-freedom) for
more.

~~~
tptacek
That's not really a reasonable argument. Signal makes a profound UX tradeoff
to protect metadata by not requiring servers to store it in the first place:
it drafts off people's phone contact lists, and thus everyone who uses it
needs to be identified by a phone number.

Matrix doesn't have any special way of avoiding that tradeoff. It just takes
the other end of the trade: Matrix servers are exposed to valuable metadata,
so that people can use whatever identifier they want.

And, of course, the flip side of Matrix's "freedom and liberty" federalized
design is that it is May 7, 2020, and the project is just now announcing E2E
by default for private conversations. This is exactly why, years ago, Moxie
Marlinspike wrote his post arguing about the downsides of federalization. It
sure looks like his predictions were borne out!

I think both of these projects are valid and important, and that they have
different goals and audiences, and we do people a disservice when we pretend
like they're in any kind of serious competition. Matrix is what you'd replace
an IRC server with. Signal is what you'd tell an immigration lawyer to use for
messaging.

~~~
comex
> And, of course, the flip side of Matrix's "freedom and liberty" federalized
> design is that it is May 7, 2020, and the project is just now announcing E2E
> by default for private conversations. This is exactly why, years ago, Moxie
> Marlinspike wrote his post arguing about the downsides of federalization. It
> sure looks like his predictions were borne out!

I'm skeptical that much of _this particular_ delay has to do with federation,
as opposed to things like differing priorities and general project velocity.

Why? Because Matrix is not yet as successful or as diverse as XMPP, the
example Moxie gave in his blog post. My impression is that Matrix has one main
server implementation (Synapse) that everyone uses, and one main client
implementation (Riot) that E2E encryption was added to. And the company
developing Synapse and Riot is also developing the spec, so it's completely
coordinated. Alternate clients and servers exist, but they're very much
"alternate"; I don't think anyone was waiting for them to implement anything
before making this announcement.

I could be wrong. I'm not involved in Matrix development, or even a Matrix
user. But that's my impression from some quick Googling.

If I'm right, the only real cost of decentralization at this point was having
to (a) design the protocol itself to support federation and (b) document the
protocol as part of the Matrix spec. That's not nothing, but it's small
potatoes compared to the kind of massive ecosystem fragmentation Moxie was
talking about.

~~~
Arathorn
My take on this is:

Yes, Matrix’s development would go way faster (6-10x is my estimate) if it
wasn’t decentralised. Huge amounts of effort goes into designing a system
where you have multiple servers (or peers in p2p) which can’t be trusted, and
where the behaviour needs to be formally specified in a neutral public spec
that can be independently implemented. You have to layer the spec into
abstractions which ensure the lower layers are stable and relatively frozen
such that folks can build on them confidently, but the higher layers can
evolve and experiment as rapidly as possible.

However, we think this is an acceptable cost in exchange for building an open
network / protocol / ecosystem like Matrix. Freedom is important.

As comex points out, we’ve tried to mitigate slowness by developing the core
of Matrix (protocol and reference server and reference clients) by the same
logical team rather than by vying factions - which has certainly helped, but
only as an incremental factor.

The fact it took us 3 years to exit beta for E2EE and turn it on by default
reflects more that we chose a large scope (interactive verif, cross-signing,
encrypted key backups, etc all break new ground, afaik), had to make it
decentralised, and also reflects prioritisation (encryption is not our only
focus).

So yes, it takes longer to build Matrix than a centralised e2ee messenger. Or
longer to build bitcoin than paypal. Or the Web than AOL. But we think it’s
worth it.

------
rattray
Folks who have tried Matrix/Riot and Slack – how does the product quality
compare?

Slack has many issues (little bugs, latency, notification issues, the shitshow
markdown editor) but overall delivers a smooth product experience IME. When
you self-host Matrix, do you typically get great perf without much effort? Is
the product experience of the Riot client smooth and complete?

~~~
x3haloed
In my experience, Matrix and Riot are great. I love the protocol and concepts
around it, and Riot was much higher quality than I expected it would be. Since
trying it out for a while a few months ago, I have since abandoned it,
however, because operating my own Synapse server was just too much work.

Specific pain points were:

\- setting up SSL - getting Let’s Encrypt certs onto a server without a web
server was a pain, and keeping them up to date was even worse. I would love to
see ACMEv2 support integrated into Synapse for painless SSL setup.

\- TURN server - if you want to use voice chat, you need to set up a separate
TURN server, which has its own set of challenges. Again, I would love to see a
solution integrated into Synapse.

\- Video chat - Even with a TURN server in place, video chat requires a
separate plugin to work. Jitsi is recommended, I believe. Yet again, I want
this integrated into Synapse and Riot.

\- Federation - Federation is part of what makes the Matrix protocol so great,
but it was a huge pain to configure in Synapse. I spent hours to get it
working, and it still had quirks about matrix.mydomain.tld vs mydomain.tld. I
would like to see this simplified.

Probably the thing I was happiest about is that a ton of administrative
settings are easy to work with in the Riot web client.

Keep it up, guys! I hope Matrix takes over the world, and I hope to come back
some day.

~~~
Arathorn
Sorry to hear that :( There are two things we've tried to do to fix it:

1) Running Synapse really isn't that hard if you follow best practices... but
I think we've done a bad job of communicating those best practices; instead
Synapse's INSTALL.md lays out tonnes of different options and expects folks to
pick their poison. I tried to fix this a few weeks ago by sitting down and
recorded a dorky video to try to steer folks through best practices for
setting up Synapse + certbot + Jitsi:
[https://matrix.org/blog/2020/04/06/running-your-own-
secure-c...](https://matrix.org/blog/2020/04/06/running-your-own-secure-
communication-service-with-matrix-and-jitsi). (I need to extend it to coturn,
but again, coturn should be straightforward. I don't think we should be baking
TURN into Synapse though!). You could also shove everything in Docker and
forget about it.

2) Peer-to-peer Matrix will let you get up and running without even needing a
server. This is progressing alarmingly rapidly at the moment -
[https://p2p.riot.im](https://p2p.riot.im) is a version of Riot/Web which
installs a homeserver (Dendrite) in your browser as a WASM service worker.
It's alpha, but it mostly works pretty well, and is hopefully the shape of
things to come - to let people have autonomy over their comms without ever
needing to understand SSL, TURN, etc.

~~~
x3haloed
I’m getting the following error when using the P2P instructions. Is this
likely an from an outage?

[https://photos.app.goo.gl/myGNh77ukXWgqaVX9](https://photos.app.goo.gl/myGNh77ukXWgqaVX9)

~~~
Arathorn
[https://p2p.riot.im](https://p2p.riot.im) is a webapp and runs in browser.

------
godelski
On HN I'm always seeing a fight between Signal and Matrix. Can someone explain
this to me? As far as I see it: Signal replaces SMS; Matrix replaces
Slack/IRC. These seem like different products that work in different spaces.

~~~
tptacek
Among technologists, the two most divisive aspects of Signal are that it
requires phone numbers, and that it isn't (and likely won't ever be) federated
--- that is, you can't run your own Signal server and be accessible to people
using ordinary Signal clients.

Matrix doesn't use phone numbers, and is federated (that's what makes Matrix
interesting), so it's naturally the "antidote" suggestion on threads when
people bring up these aspects of Signal.

The fact is that they're not really comparable projects; they have different
audiences and different goals. People have an innate narrative bias that
constant hunts for horse races to spectate, and so you'll see a lot of "Signal
vs. Matrix" arguments, but it's an artifact, not anything substantive.

~~~
atomicnumber3
I know you're just citing the arguments, but I can't help but respond.

I always see Signal as being "really good" crypto. Bulletproof? No, surely
not. That doesn't exist. If I were a dissident or something I would be using
gpg religiously and all that jazz.

But is signal _____significantly_ __ __better than basically every mainstream
sms-like thing? Absolutely! imessage, sms, mms, whatapp, facebook messenger,
whatever google 's current chat app is, etc. All of them don't even try to be
a secure/privacy-respecting chat tool and reall y make no secret that they're
usually totally the opposite (facebook messenger....).

So when it comes to getting my parents onto something that sends videos of the
kids real good and also will make dragnet state surveillance efforts a bit
harder, I pick Signal.

~~~
tptacek
The cryptography in Signal is substantially better than that of GPG. You would
have a very hard time finding a cryptography engineer that disagreed with
that.

------
sm4rk0
Perfect timing:
[https://news.ycombinator.com/item?id=23102430](https://news.ycombinator.com/item?id=23102430)
Congratulations!

~~~
jason0597
Pretty sure the person posting the Matrix page knew this

~~~
Aaronn
Actually this was all released a couple of days ago, just took a bit of time
for them to write the blog post.

------
snvzz
Tox is:

* Still alive.

* Still open source libraries and most clients.

* Still mandatory e2e encrypted. (unlike matrix)

* Still always-on full forward secrecy. (unlike matrix)

* Still full p2p. (unlike matrix)

* Still works fine.

Just saying.

Why isn't Tox more popular? The difference has to be the amount of
money/effort spent in marketing.

~~~
zajio1am
How it work through NATs?

~~~
snvzz
It implements hole punching.

~~~
zajio1am
Hole punching works for firewalls, but is unreliable for NATs. Note that most
home routers are Linux based, and Linux uses symmetric NAT, where hole
punching does not generally work reliably.

~~~
snvzz
It also implements relays, if both sides can't be reached.

And it works with TCP, if it can't be made to work with UDP.

And it supports ipv6.

You're pretty much covered.

------
Arathorn
See also
[https://news.ycombinator.com/item?id=23092269](https://news.ycombinator.com/item?id=23092269)
and
[https://news.ycombinator.com/item?id=23088852](https://news.ycombinator.com/item?id=23088852)
(these should be merged perhaps)?

------
gramakri
For those looking to selfhost synapse and riot, we (cloudron.io) recently made
both these packages stable. If you need help in setting them up, happy to help
here (even if not on cloudron)

------
y7
Is there a Python SDK that supports encryption well yet? I have a simple
command line script to send a message to a Matrix room. About three months ago
I tried to add encryption, but apparently the old matrix-python-sdk is
deprecated in favor of matrix-nio, but encryption support in the latter was
very marginal still.

~~~
Arathorn
matrix-nio's encryption is very robust now, but by far the easiest way to hook
up a simple commandline script is to pipe it through pantalaimon
([https://github.com/matrix-org/pantalaimon](https://github.com/matrix-
org/pantalaimon)) - which acts as a daemon to offload E2EE from your script,
using matrix-nio under the hood.

------
satsoul
Have you guys tried Olvid [https://olvid.io/en/](https://olvid.io/en/), they
removed the servers principle entirely. Worth trying

------
some_furry
Yay! This is the right move for their users.

There's still a ton of work left to do, but I'm thankful for all the hard work
that went into making this possible.

------
fack
w00t! my computer club hosts a homeserver and it's been running so smoothly
since we upgraded.

~~~
im_dario
How is memory consumption going? I'm waiting for improvement in this area or a
stable release of Dendrite [0] (hoping it has a reasonable memory usage).

0: [https://github.com/matrix-org/dendrite](https://github.com/matrix-
org/dendrite)

------
est
I heard there's a telegram-like client for Matrix? Is it still around?

~~~
Arathorn
nheko is pretty similar to TG and is reborn and evolving well after a hiatus a
few years back: [https://github.com/Nheko-
Reborn/nheko](https://github.com/Nheko-Reborn/nheko)

------
john_alan
Does this use ephemeral secrets/is it forward secret?

Can see this info in the blog.

~~~
Arathorn
It depends on the layer. Matrix used Olm for device-to-fecice encryption,
which is a clone of Signal’s double ratchet, and is PFS. For message history
however we use Megolm, which is a simpler hash ratchet which is synchronised
across the members of a group by sharing its state over Olm. You typically
replace the Megolm ratchet every 100 msgs or 1 week, but depending on how fast
you do that and how long you store the keys for, you can get PFS. The problem
is that most users want to be able to access their chat history from the
server, which is by definition incompatible with PFS as you have to keep the
message keys around to decrypt the msgs.

------
ex3ndr
How they made scalable webrtc end-to-end encrypted? I guess it is not scalable
(~5 members max).

~~~
Arathorn
Multi-way video conferencing in Matrix isn't e2ee yet; the e2ee-by-default
here refers to private group chats, DMs, and 1:1 video/voip calls.

Once Jitsi lands their E2EE support (hopefully using Matrix's E2EE for key
management, c.f.
[https://news.ycombinator.com/item?id=22855407](https://news.ycombinator.com/item?id=22855407))
then we'll get E2EE video conferencing too.

Until then, Matrix (but not Riot) also supports E2EE video conferencing via
full mesh webrtc, but as you say, it scales to relatively few users.

~~~
ex3ndr
Insertable streams are not going to help much since if it encrypts every frame
this would mean that every frame will be encrypted and therefore couldn't be
compressed. It doesn't make sense actually since you could just encrypt RTP
payloads instead keeping service messages in plain text.

~~~
Arathorn
Insertable streams let you encrypt the compressed media.

WebRTC doesn’t give you hooks to re-encrypt the SRTP payloads.

~~~
ex3ndr
How does this visualisations are done? How it could "decode" incorrect image
and display as a demo in various articles?

I do not believe that video codecs are able to decode over "encrypted" data
and produce some video stream.

~~~
Arathorn
the point of insertable streams is that you can hook into the compressed
payloads and encrypt them after compression, and then decrypt them before
decompression. The codec never sees encrypted data.

