Hacker News Reader

Hacker News

Comment by ttybird | Hacker News Reader

Full thread

ttybird

What does this solve that xmpp and matrix do not?

And still no e2ee, after all these years.

View on HN

IRC is mostly used for public chatrooms, so what the purpose of E2EE would be anyway?

If that was the case then \query would not exist.

There are (were) many smaller groups that use private channels. It is also how me and my first bf and some of my friends ended up talking.

OTR is a de-facto standard for e2ee on IRC, it predates Matrix by a decade.

And yet almost nobody who uses irc uses it, unlike omemo (xmpp) and olm (matrix). Its encryption also predates matrix by a decade, its dh prime is only 1.5k bits big.

True, people on IRC usually don't mind conversations being public. Check out OTRv4 though, they are working on modernizing the encryption: https://bugs.otr.im/otrv4/otrv4

Is anyone using IRC for private conversations? I only see it being used for public chat rooms where every message is even getting recorded to a public archive; it's one of the rare cases of a messaging system where people have nearly zero concern for privacy. (I'm all for having the option of course, just pointing out a cultural reason why e2ee wouldn't have much uptake since nobody cares)

I responded to that in another message but yes, many people do. Either via direct messages or small private channels.

But even if they didn't, there would be no reason not to move their public conversations to the protocol that they use for direct messages.

e2ee is a challenge for any system that did not have it built-in in the first place, and even more so when the system is open (in the sense of anyone being able to implement their own client/server, and server federation). At the end of the day we will probably not be able to do much better than using TLS to secure IRC, and will just have to trust the server. OTR is OK for those who choose to use it, but it is not universal and requires too much coordination with whoever you are trying to chat with (you have to answer challenges like, "I like my IRC client, I do not care that it doesn't support OTR, we are just chatting about TV shows so who cares?").

Dunno about that. XMPP and Matrix seem to have solved this issue. Plus implementing TLS is much more difficult than implementing e2ee so I do not get the argument.

TLS is widely supported with dozens of available implementations ready-to-use in many different programming languages and on many different platforms, and it basically comes free for any browser-based implementation. Those implementations also receive a lot of attention, and because of that library support it is much easier to update an application that uses TLS than some purpose-built chat protocol. For example, let's say a new EC attack is discovered and we have to move everyone to a different set of curves (e.g. maybe P256 is found to be insecure and we all have to switch to P521). An OpenSSL update will be pushed out a lot sooner, and will be used by far more client applications, than the updates to all of the hundreds of chat clients that need whatever chat-specific e2ee protocol updated.

At the end of the day, even with all problems that exist in TLS implementations, I have a lot more faith in TLS than I do in some college student's hacked together web chat client's e2ee implementation. As for XMPP, just how widely available is OMEMO in XMPP client software? The last time I tried to deal with XMPP and e2ee I was constantly confronted with clients that did not support this or that protocol. I can't speak for Matrix, maybe it "solved" the problem, but as I said if e2ee was not part of the standard from the beginning it is going to be hard to push it out as an afterthought.

Solution: use a library for the e2ee, multiple clients and even the group that makes the standard could contribute. This is what matrix did. On the other hand Dino (xmpp) uses vala bindings for the official "libsignal-protocol-c".

Your favorite curve is suddenly vulnerable? Use a library like libsodium which has a solid track record and will be updated to replace the default algorithm if there is a need.

I will take signal's "hacked together" e2ee implementation over openssl.

As for clients without omemo support, I did not have any issue so far.

Reply on news.ycombinator.com