OTRv4+ – full OTRv4 with post‑quantum crypto (ML‑KEM/ML‑DSA) in a single‑file Python
Posted by cryptocreeping@reddit | Python | View on Reddit | 8 comments
What My Project Does
OTRv4+ is a complete implementation of the OTRv4 protocol that adds post‑quantum cryptography to every layer. It includes:
· Full OTRv4 features: fingerprint trust management, SMP (Socialist Millionaire Protocol), double ratchet with brace key.
· Post‑quantum additions: Triple X448 + ML‑KEM‑1024 for key exchange, Ed448 ring signatures + ML‑DSA‑87 for authentication (making auth PQ‑secure – unlike Signal’s PQXDH), and fresh ML‑KEM‑1024 at every DH epoch for the ratchet.
· Built as a single Python file (\~12k lines) plus three small C extensions (performance‑critical crypto glue).
· Runs on IRC, supports I2P/Tor, and works on Termux (tested on a phone).
· Includes a WeeChat plugin (ready for testing – I haven’t fully tested it yet).
Target Audience
· Security researchers / cryptography enthusiasts who want to experiment with post‑quantum OTR on real IRC networks.
· Termux users looking for a portable, encrypted chat solution on their phone.
· WeeChat users who want end‑to‑end encrypted IRC with post‑quantum protections (beta testers welcome).
· Python developers interested in single‑file protocol implementations, OpenSSL 3.5+ FIPS providers (no liboqs), or auditing a moderately sized crypto codebase.
Not intended for production use yet – it’s a research prototype and testing ground.
Comparison
· vs. Signal’s PQXDH: Signal’s handshake adds ML‑KEM but explicitly states “Authentication in PQXDH is not quantum‑secure”. OTRv4+ uses ML‑DSA‑87 to make authentication post‑quantum as well (trade‑off: loses PQ deniability – a known open problem).
· vs. liboqs‑based solutions: This project uses OpenSSL 3.5+ native FIPS 203/204 providers – no external liboqs dependency.
· vs. other OTR implementations (libotr, etc.): Those are not post‑quantum and don’t implement OTRv4’s modern ratchet. OTRv4+ aims for full spec compliance plus PQ hardening.
· vs. single‑file Python tools: Most crypto protocols are spread across many files. This keeps the whole OTRv4 state machine and PQ logic in one file for easier auditing.
Try it
```bash
git clone https://github.com/muc111/OTRv4Plus
```
Requires Python 3.9+, OpenSSL 3.5+, and a C compiler. Works on Linux, Termux, probably other Unix‑likes. Auto‑detects I2P/Tor/clearnet from hostname.
Feedback, issues, PRs welcome. For commercial licensing, open an issue with label commercial-license.
Cheers!
0r0B0t0@reddit
Vibe coded cryptography? No thanks
cryptocreeping@reddit (OP)
haakon@reddit
Be aware that this was vibe coded. For example, here's the author removing the LLM's response that was committed accidentally: https://github.com/muc111/OTRv4Plus/commit/93ceabbc67303e29cbfbbbc8a061a2899d37e9d9
There's nothing inherently wrong with vibe coding, but in this case, consider:
cryptocreeping@reddit (OP)
You’ve made a few claims. Let me correct them.
“Vibe coding” / AI use Yes, I used AI. It’s a tool, like a compiler or a linter. I don’t owe anyone a disclaimer. The code works, passes 224 tests, and implements the full OTRv4 spec plus NIST Level 5 post‑quantum crypto. If you think AI can’t produce working crypto, you haven’t been paying attention to the last two years of progress.
Git history / “pretends everything is hand‑coded” I never pretended anything. The public repo has a short history because I squashed months of offline work before pushing – a standard practice to remove credentials and experimental dead ends. That doesn’t make me “dishonest”. It makes me pragmatic. The DEVELOPMENT.md file (not .mb, that was a typo) explains the timeline. Read it.
12 months of vibe coding – is it a toy? I spent 12 months on this. Not full‑time – evenings, weekends, on a phone in Termux. The result is a working IRC client with DAKE, double ratchet, SMP, ML‑KEM‑1024 brace KEM rotation, and ML‑DSA‑87 hybrid auth. It’s not a toy. It’s not production‑hardened either – I never claimed it was. It’s a practical implementation that you can run today on I2P.
Post‑quantum bugs You’re right that PQ crypto is subtle. That’s why the critical parts are in C extensions calling OpenSSL 3.5+’s FIPS‑validated providers – not in AI‑generated Python. If there’s a bug, find it. I’ll fix it. The code is open.
Bottom line You don’t have to trust me. Trust the code, or don’t use it. But don’t accuse me of lying when I’ve been transparent about the timeline and the tools I used. If you want to help, open a GitHub issue with a specific vulnerability. Otherwise, this is just noise.
haakon@reddit
Thanks for AI-generating that response to me. I'm not going to engage with a robot.
cryptocreeping@reddit (OP)
😂
No_Soy_Colosio@reddit
Word salad
AutoModerator@reddit
Hi there, from the /r/Python mods.
We want to emphasize that while security-centric programs are fun project spaces to explore we do not recommend that they be treated as a security solution unless they’ve been audited by a third party, security professional and the audit is visible for review.
Security is not easy. And making project to learn how to manage it is a great idea to learn about the complexity of this world. That said, there’s a difference between exploring and learning about a topic space, and trusting that a product is secure for sensitive materials in the face of adversaries.
We hope you enjoy projects like these from a safety conscious perspective.
Warm regards and all the best for your future Pythoneering,
/r/Python moderator team
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.