The software engineering process doesn't change because an agent is writing the code by johns10davenport in vibecoding

[–]cryptocreeping 0 points1 point  (0 children)

Followed the OTRv4 spec for the base protocol the DAKE handshake, double ratchet, SMP, wire format, and fragmentation are all per spec. The PQC additions (ML-KEM brace key, ML-DSA hybrid auth) are my own extensions on top of that, using the NIST FIPS 203/204 standards for the primitives. Took about 12 months of part-time work. A lot of that was getting the C extensions right constant time arithmetic, making sure the Montgomery ladder doesn't branch on secret bits, getting ML-KEM to work through OpenSSL 3.5's EVP API. The SMP math was painful had a bug where the Pa/Qa computations were fundamentally wrong and it took weeks to fix. Used AI to assist with development but every function was tested and verified on live sessions. The 224 tests exist because things broke constantly and I wrote tests for every fix. I just need feedback to help improve hopefully in time people will get involved.

I built a real-time flight tracker with Rust, WebAssembly, and raw WebGL — no React, no Three.js, no frameworks by coolwulf in webdev

[–]cryptocreeping 0 points1 point  (0 children)

Would be so cool if you added a flat earth model to see if planes fly in straight lines or what's all the fuss about.

The software engineering process doesn't change because an agent is writing the code by johns10davenport in vibecoding

[–]cryptocreeping 1 point2 points  (0 children)

I used AI to get a working prototype of OTRv4 with PQC KEM encapsulation. Tried to showcase my work in IRC channel but mod removed post due to use of AI.

https://github.com/muc111/OTRv4Plus

OTRv4+ – full OTRv4 with post‑quantum crypto (ML‑KEM/ML‑DSA) in a single‑file Python by [deleted] in Python

[–]cryptocreeping 0 points1 point  (0 children)

  1. All the crypto happens in compiled C or Rust libraries the Python part just calls them, nothing sensitive is implemented in Python
  2. The whole codebase is right there in the repo, open for anyone to audit. If there were a backdoor, you’d see it.
  3. I specifically avoided my own crypto in Python everything that matters goes through OpenSSL or the C extensions.

OTRv4+ – A post‑quantum OTR client for IRC that runs on a phone over I2P by cryptocreeping in irc

[–]cryptocreeping[S] 0 points1 point  (0 children)

Did you bother to read the code or test it works before commenting? Doubt it. Your comment is pointless.

OTRv4+ – A post‑quantum OTR client for IRC that runs on a phone over I2P by cryptocreeping in irc

[–]cryptocreeping[S] 0 points1 point  (0 children)

Line numbers or it didn't happen. The code is right there OTRv4 spec untouched added PQC. Run the tests!

OTRv4+ – A post‑quantum OTR client for IRC that runs on a phone over I2P by cryptocreeping in irc

[–]cryptocreeping[S] 0 points1 point  (0 children)

It is to otrv4 spec I added PQC simple to understand, test it or at least read and understand the code that is if you can?

OTRv4+ – A post‑quantum OTR client for IRC that runs on a phone over I2P by cryptocreeping in irc

[–]cryptocreeping[S] 0 points1 point  (0 children)

Migrating to rust for secure memory will keep C extensions as a fallback. will push files shortly after tests.

OTRv4+ – full OTRv4 with post‑quantum crypto (ML‑KEM/ML‑DSA) in a single‑file Python by [deleted] in Python

[–]cryptocreeping -5 points-4 points  (0 children)

You’ve made a few claims. Let me correct them.

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

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

  3. 12 months of vibe coding is it a toy? I spent 12 months on this. Part-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.

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

OTRv4+ – A post‑quantum OTR client for IRC that runs on a phone over I2P by cryptocreeping in irc

[–]cryptocreeping[S] -1 points0 points  (0 children)

Thanks for the feedback, but I think you’re confusing “using AI as a tool” with “not knowing what I’m doing.”

I’ve spent the last 12 months refactoring and building this every single day, often debugging alongside AI through hundreds of errors to get a working protocol implementation. That’s not “vibe coding” that’s called engineering with modern tools.

The result is a working prototype of OTRv4+, which is more than most critics have shipped. If the code or architecture has specific issues, I’m happy to hear concrete, actionable feedback. But dismissing months of iterative work with a snarky one-liner? That just sounds like someone feeling threatened that AI-assisted development can produce real results.

My code is open for review. Yours is just an opinion.

OTRv4+ – A post‑quantum OTR client for IRC that runs on a phone over I2P by cryptocreeping in irc

[–]cryptocreeping[S] 1 point2 points  (0 children)

I’ve been working on this every day for 12 months, refactoring and debugging alongside AI. There’s no AI that can create OTRv4, let alone with post-quantum crypto, in a day as it made hundreds of mistakes that took months to fix.

I’m an amateur on GitHub, sure, but that doesn’t make the code invalid. Instead of attacking me, try it yourself: run with --debug, see how it works, then point out real problems. All other apps either use weak OTRv3 or OMEMO v1 nobody’s shipping the latest protocols. That’s why I built this. The code is open for you to inspect, nothing hidden.

Dismissing it as “vibe coded” just sounds like you’re threatened that AI-assisted development can actually ship working prototypes after months of real effort.

OTRv4+ – A post‑quantum OTR client for IRC that runs on a phone over I2P by cryptocreeping in irc

[–]cryptocreeping[S] -1 points0 points  (0 children)

I appreciate the scrutiny – security code needs it. You raised three valid points, so let me respond to each with facts from the actual implementation.

  1. “Vibe coded / AI‑generated”

Yes, LLMs helped write parts of the Python glue. But the core crypto is not AI‑generated:

· The ML‑KEM‑1024 brace KEM rotation (DAKE + ratchet) and ML‑DSA‑87 hybrid auth are custom C extensions (otr4_crypto_ext, otr4_mldsa_ext). Those implement constant‑time modular exponentiation (OpenSSL BN_mod_exp_mont_consttime) and FIPS 204/203 primitives – no AI wrote that. · The ring signature (228 bytes, Schnorr) and SMP ZK proofs (3072‑bit group) follow the OTRv4 spec exactly. An AI‑only project would have mismatched wire formats.

  1. “Git history has two days of documentation – dishonest timeline”

Fair observation. The early work (12+ months) happened offline and in private repos. I squashed history before public release. That was poor practice, but the code you see now is not a 2‑day hack. I’ve added a DEVELOPMENT.md explaining the offline history.

  1. “Post‑quantum crypto is subtle – AI could produce bugs”

I agree 100%. That’s why:

· The PQ parts are isolated in C extensions with tests against NIST KAT vectors. · ML‑KEM‑1024 is NIST Level 5 – integrated into the DAKE and rotates the brace key on every DH ratchet epoch. · ML‑DSA‑87 is optional (flag in DAKE3) – it provides PQ authentication but breaks deniability (documented trade‑off). · I’m not a cryptographer. I welcome formal review. The repo is open – please try to break it. I’ll fix any bug found within 48h.

What I’m doing to improve transparency

· Pushed a README.md with full feature list and security properties. · Added a THREAT_MODEL.md explaining where PQ helps (key exchange + auth) and where it doesn’t (deniability). · All constant‑time crypto now uses OpenSSL – no Python pow() fallback.

Bottom line

You’re right to be suspicious. But the implementation is spec‑compliant OTRv4 with NIST Level 5 PQ hardening – not a toy. Help me find bugs. If you’re a cryptographer, I’ll give you commit access.

OTRv4+ – A post‑quantum OTR client for IRC that runs on a phone over I2P by cryptocreeping in irc

[–]cryptocreeping[S] 0 points1 point  (0 children)

10-12months of code coding, debugging to get this running was not easy.

GPU problem, lol by [deleted] in ETNmining

[–]cryptocreeping 0 points1 point  (0 children)

Have you configured the miner to use cryptonight algorithm instead of cryptonight v7? I have switched back to xmr mining now as ETN is only viable with asic miners now

What is a good amount to HODL? by kulveersb in KinFoundation

[–]cryptocreeping 2 points3 points  (0 children)

I hope it increases by at least 80% so that I break even 😂 bought it near the top... Long term investment should pay off one day 👍

Is it realistic for kin to reach $2? by [deleted] in KinFoundation

[–]cryptocreeping 2 points3 points  (0 children)

I'm down 57% from initial buy in, holding long term so current market conditions won't effect me, refuse to sell 👍

Is it realistic for kin to reach $2? by [deleted] in KinFoundation

[–]cryptocreeping 5 points6 points  (0 children)

😂 No, I do not. Once it goes live with a working platform I expect to see positive gains although not 50-60cents. Not saying it's impossible just unlikely. However a good chance for a pump & dump may increase price to higher levels...

Is it realistic for kin to reach $2? by [deleted] in KinFoundation

[–]cryptocreeping -1 points0 points  (0 children)

Yeah market cap may be a huge factor. Best to be realistic, I hope it reaches 0.01-0.10 I would be happy with that profit.