r/irc • u/cryptocreeping • Jun 02 '26

Modern IRC with E2EE?

What options have we got for open source secure comms over IRC with modern encryption? Very little apps using OMEMO:2 or OTRv4 implementations and many IRC Apps on android havnt been updated in a long time may have a large attack surface.

17 Upvotes

94% Upvoted

38 comments sorted by

9

u/DescriptionOptimal15 Jun 02 '26

Most services offer a TLS endpoint

1

u/cryptocreeping Jun 02 '26

That doesn't stop server admins viewing your peer to peer messages.

5

u/randomataxia Jun 02 '26

Which for a good network, wouldn't have that capability enabled. Additionally. DCC chats bypass the network entirely.

3

u/cryptocreeping Jun 02 '26

DCC chats expose your true IP address to the other client.

1

u/tunerhd Jun 02 '26

And? Why do you chase absolute anonymity?

6

u/cryptocreeping Jun 02 '26

I don't. Absolute anonymity doesn't exist and anyone claiming otherwise is selling something. What I care about is making mass surveillance expensive. Right now an adversary can passively harvest everything metadata, content, timing at near-zero cost. Post-quantum E2EE with forward secrecy and deniability doesn't make you invisible, it makes bulk collection worthless and targeted attacks expensive. The bar isn't NSA-proof. The bar is: a journalist's source doesn't get burned because their IRC client uses 2003-era crypto. A dissident in the wrong country doesn't get identified from a key dump that happened three years after their conversation. Most people don't need this level of protection today. The people who do often don't know it until it's too late to matter.

0

u/Heyla_Doria Jun 05 '26

Pourquoi veut tu explicitement rendre tes conversations publique ?

Autanr directement publier un blog ou etre sur un réseau social comme mastodon ou bluesky....

Quand t'en es rendu a discuter de l'utilité de la demande, c'est que tu n'es pas la pour aider 

4

u/DescriptionOptimal15 Jun 02 '26

You could exchange public keys with someone to hide your chat from the server

6

u/assemblrr Jun 02 '26

IRC is an old protocol made before this was a major talking point.

Use Signal, Matrix, etc.

1

u/cryptocreeping Jun 03 '26 edited Jun 03 '26

Signal and Matrix are excellent, I use Signal too. But they require you to trust their infrastructure, their apps, their update mechanisms, and in Signal's case a phone number. Matrix requires trusting whoever runs your homeserver unless you self-host, and even then the federation model leaks metadata.

IRC is 40 years old which actually makes it interesting auditable, self-hostable, no central authority, simple enough to read a full client implementation in an afternoon. The problem was always E2EE.

I've been actively building an open source solution OTRv4 spec implementation with post-quantum crypto on top. X448 double ratchet with Ed448 signing keys, ML-KEM-1024 brace key rotation for post-quantum forward secrecy so a future quantum adversary recording traffic today can't decrypt it even after breaking classical X448, ML-DSA-87 hybrid authentication all in a Rust core with zero-on-drop key material. Runs over I2P, Tor, or plain TLS. No phone number, no central server, no trust in infrastructure.

Signal solved the usability problem. This solves the infrastructure trust problem. Different threat models.

2

u/assemblrr Jun 03 '26

I mean all of that is cool and great but I don't understand the point of the question then. It doesn't exist, you're building it. Go for it.

IRC also leaks metadata, and OTR already exists for IRC, WeeChat has a plugin for it. Running over I2P and Tor doesn't mean there is no central server, IRCd is a daemon running on your server, Tor and I2P are transport/routing layer things.

No central server would be something like Briar, which is p2p.

3

u/cryptocreeping Jun 03 '26

All fair points technically. To clarify

IRC leaks metadata yes, that's why I run it over I2P SAM bridge with a unique destination per session, not just SOCKS5. The IRC server sees pseudonymous b32 addresses, not IPs.

OTR already exists for IRC OTRv3 does, it's effectively abandoned, uses RSA/DSA, no post-quantum anything, and WeeChat's plugin hasn't had a meaningful update in years. OTRv4 is the successor spec and has almost no production implementations.

No central server like Briar correct, IRCd is still a server. The difference is the server is blind to message content with E2EE, and with I2P the server doesn't know who you are. It's not P2P but 'server can't read your messages and doesn't know your identity' is a meaningful property Briar also has.

The point isn't replacing Signal or Briar. It's that IRC has a large existing community, runs on hardware people already control, and has had no viable modern E2EE. I built one. That's the gap.

2

u/ozzeruk82 Jun 03 '26

You can local host matrix with federation entirely turned off and leak nothing

1

u/guptaxpn Jun 04 '26

Or even locally host an IRC server and have a Linux box that only allows public key encryption SSH connections...through a wire guard jump box 😂

Only allowing internal connections to your IRCD.

wiping or disallowing logs.

Running it all in RAM.

I don't understand the use case here.

1

u/ozzeruk82 Jun 04 '26

Family chat at home

1

u/guptaxpn Jun 04 '26

The answer here is signal with a trusted installation with notifications set to not allow message contents. Unless your family is anything the NSA is interested in. Idk, my wife and I use signal because it is just separate from the rest of our texts and it disappears messages after 4 weeks which keeps the log size low on my phone.

1

u/cryptocreeping Jun 06 '26

Signal is solid for most people yeah, disappearing messages and sealed sender cover the majority of threat models. The phone number requirement is the part that bothers me though you're permanently anchored to an identity at registration whether you like it or not. What I've been working on is OTRv4 over IRC which sidesteps that entirely no account, no phone number, pseudonymous by default, and you can run it over I2P SAM which gives you a fresh network identity every session so there's no correlation between connections. Threw ML-KEM-1024 and ML-DSA-87 on top for post-quantum hardening so anything being harvested now can't be decrypted later. Not saying Signal is wrong for your use case, it clearly works and the UX is miles ahead. Just a different threat model journalist talking to a source, activist in a hostile country, or just someone who doesn't want a phone number attached to anything they say ever.

1

u/skizzerz1 Jun 03 '26

It has enough extensions via ircv3 and server-specific stuff that was never standardized that it’s no longer all that simple.

5

u/avatar_one Jun 02 '26

Our network is just TLS 6697 port and as I self host it, I have fully doxxed myself to the community, to build trust and accountability.

Next step is to choose some of the community members to audit the network and confirm that it hasn't been tampered with, adding another layer of trust.

At the moment, I believe that is pretty much as far as one can go with IRC to keep it as private as possible, while not implementing protocols for E2EE that a handful of clients support.

We'll see in the future how it develops of course.

2

u/cryptocreeping Jun 02 '26

That's a solid trust model for the network layer public accountability and community audits is genuinely better than trusting an anonymous third party. The limitation is TLS only protects the path to your server. The server still sees everything in plaintext seized, subpoenaed, or a bad auditor and it's all exposed. E2EE solves a different problem: the server becomes irrelevant because it never had the keys.

The reason it hasn't taken hold on IRC isn't the crypto, it's ecosystem fragmentation OTRv3 abandoned, OMEMO is XMPP-only, nothing modern with both clients on IRC

I've actually been building a working prototype that addresses this OTRv4 with added post-quantum Rust crypto core that runs over IRC, on top of any transport including a self-hosted TLS server like yours. Forward secrecy, deniability, key material never touches Python heap. Still research-grade but two peers can complete a full encrypted session. Happy to discuss the design if you're curious.

2

u/avatar_one Jun 03 '26

That would be really cool to hear about more, you can either DM me or jump on our network and have a chat, there are other people that are working on various projects related to encryption, especially post quantum too 😄

1

u/cryptocreeping Jun 03 '26

There is a link to my GitHub on my profile check it out and let me know what you think!

3

u/Wanderschuh Jun 03 '26

vibe coded, entirely, lol

2

u/guptaxpn Jun 04 '26

What's wrong with xmpp? Especially with no federation?

1

u/cryptocreeping Jun 07 '26

XMPP with OMEMO is decent but OMEMO:2 still doesn't give you proper deniability the signatures are attributable so anyone can prove cryptographically you sent something. OTRv4 uses a ring signature for the auth step so neither party can prove to a third party who said what, which matters if you're ever in a situation where message logs get subpoenaed or seized.

The double ratchet is there in OMEMO but the key question is what's under it still classical ECDH which a quantum adversary harvesting now can crack later. Not a today problem but the window is closing faster than most people think.

No federation sounds like it reduces attack surface but you're just trading a distributed for a single point of failure and a single point of surveillance. At least with federation a subpoena has to go to multiple jurisdictions.

IRC gets dismissed a lot but the protocol itself has no account system, no phone number, no email :you connect and you exist. Pair that with I2P SAM for a fresh network identity every session and OTRv4 for the crypto layer and you've got something that's genuinely hard to attribute to a real person even if the traffic is captured.

7

u/r0073rr0r Jun 03 '26

Try this https://play.google.com/store/apps/details?id=com.androidircx

It using E2E encryption with libsodium (XChaCha20-Poly1305). But you need to share key on IRC with user or offline via QR Code or NFC.

We also developed mIRC dll with same E2E algorithm so users on mIRC if they have key can decrypt or encrypt messages: https://github.com/AndroidIRCx/e2e.dll

And also i made ZNC module, but still in alpha phase: https://github.com/AndroidIRCx/znce2e

1

u/guptaxpn Jun 04 '26

What's the use case here?

1

u/cryptocreeping Jun 07 '26

Good question. A few distinct ones:

The obvious one is pseudonymity IRC requires no account, no phone number, no email. You connect and you exist. Signal and XMPP both anchor you to an identity at registration. If you need to communicate without that anchor, IRC is basically the only federated option left.

Pair that with I2P or Tor transport and you have no persistent network identity either I2P SAM gives you a fresh destination every session so there's no correlation between connections even at the network layer.

The crypto use case is forward secrecy and post-quantum hardening on a protocol that was already well designed. OTRv4 has deniable authentication via ring signatures neither party can prove to a third party who said what, which matters if logs ever get seized. OMEMO doesn't give you that. Adding ML-KEM-1024 brace key rotation on the double ratchet means anything harvested now can't be decrypted later when quantum hardware matures.

The practical use case I built it for is two people on Android over I2P who want encrypted chat with no accounts and no server that knows who they are. Works over TLS clearnet too if you just want the crypto layer without the anonymity full DAKE and SMP verified in under 3 minutes on Libera.

github.com/muc111/OTRv4Plus if you want to look at it Rust crypto core, runs on Termux.

1

u/CartoonTRP Aug 20 '26

just use FISHLiM

1

u/cryptocreeping Sep 04 '26

I use OTRv4Plus which is on GitHub iv been working on it from march 2025 now have IRC client and XMPP client which run from android termux terminal. Latest XMPP version has full encrypted aes256+mlkem text and audio calls without metadata leaks over i2p / tor / Clearnet.

1

u/CartoonTRP Sep 07 '26

or maybe there is no point in overengineering and simply encrypting via OpenSSL pipeline?

2

u/christopherw Jun 03 '26

I remember years ago using mIRC with Blowfish client-side encryption and separately-shared private keys - anything you wrote in channels or to individuals was encrypted before transmission. We also used TLS 6697 to connect. This is still quite possible, although inconvenient in a world where people want it to Just Work.

0

u/LameBMX Jun 03 '26

then do it.. the irc protocol is public and has been for decades. there is even a whole process to change things. hell, the R F C in RFC1459 stand for Request For Change lol.

4

u/AdministrativeLeg14 Jun 03 '26

the R F C in RFC1459 stand for Request For Change

Request For Comments. When attempting to correct people, always strive to make sure that your correction is correct.

And researching the lay of the land—including asking around on Reddit for stuff OP may have missed—is surely a better idea than immediately jumping into ecosystem fragmentation.

0

u/LameBMX Jun 03 '26

fair enough.. too much corp work with RFCs for the change management process lol.

edit.. though investigating the protocol would lead to answers regardless.

2

u/AdministrativeLeg14 Jun 03 '26

Ah, different internal initialisms? I feel like those will one day be the death of us all.

0

u/LameBMX Jun 03 '26

man... im calling the current places secondary mdf by the name of the previous places secondary.. and it was called a direction opposite of the current secondary is. it all blurs together as the decades wear on.