Hi @marlez,
Thanks for taking the time to look at this. There are real points in your message, so let me go through them.
Some background first, because it's relevant to your concern. I'm an R&D developer with 20+ years in cryptographic implementation, mostly C/ASM for embedded and secure elements. One of the stacks I wrote went through Common Criteria certification (banking, ID/passport). Until 2022 I was the original author of the crypto stack running on Ledger hardware-wallet devices. I don't mention this as an argument from authority — I mention it because your concern boils down to "can this person actually evaluate what the model produced?", and evaluating cryptographic implementations by hand is precisely what I've done for two decades.
On "AI-assisted" vs "LLM-generated": you're right that the label can undersell it. To be precise — a substantial fraction of the code was produced with Claude, and that is exactly why every such commit carries a Co-Authored-By trailer. The provenance is auditable line by line rather than hidden. I would rather over-disclose than let anyone assume it was all hand-typed.
You contrast the announcement's framing with the sentence you found in SKILL.md ("...makes a routine review actively dangerous"). Those two are not in tension — they are the same stance at two altitudes. The public line states the hypothesis (can an LLM help produce rigorous crypto rather than the plausible-but-unverified kind?); the SKILL.md line is the methodological precondition that makes the hypothesis testable instead of a matter of faith: assume a reading-based "looks good to me" is unsafe, and force the evidence onto tools. And note the direction of the asymmetry — the internal guardrail is harsher than the public framing, not softer, and it lives openly in the repo, which is how you read it. If I were spinning this, that's the first sentence I'd have deleted.
And here's the part that predates AI entirely. For cryptographic code, the primary evidence of correctness has never been code-reading. A hand-written ML-KEM is trusted because it passes ACVP/KAT vectors and shows no leakage under ctgrind/dudect — not because someone eyeballed every butterfly in the NTT. That standard of evidence is identical whether the lines were typed by a human or by a model. So "relying on tools rather than my eyes" is not an AI dodge; it is how this field validates this kind of code, and it's what I would do for my own hand-written stack too.
On the tooling being old: the lineage is old, true — Valgrind/memcheck constant-time checking and dudect (Reparaz et al., 2016) both go back years. But what's old there is the method, not a rotting binary. Uninitialised-value propagation and the leakage t-test are exactly what current CT tooling still implements, and a sound method doesn't bit-rot. The conformance side (KAT/ACVP/Wycheproof) tracks today's NIST vectors. These are the same tools I'd reach for to validate a hand-written stack; their age is a sign they've held up, not that they've lapsed.
That said — this is 0.1, and the verification chain is a baseline, not a finished product. Extending it is already tracked work: mirroring the CT harness onto the classical crate, and moving constant-time checks onto the actual targets under QEMU rather than only on the host. Beyond what's planned, a pure-Rust, embedded, side-channel-focused codebase strikes me as a good testbed for the newer constant-time verifiers as they mature — and I'd rather a project like this help exercise and push that toolin forward than merely consume it. Today's toolset is the proven floor; raising it is a direction I care about, not an afterthought.
What I do NOT claim: that the model is right, that it is better than a human, or that I fully control everything it produces. I can't claim that, and I don't. The crates are explicitly labelled unaudited, pre-1.0, not production-ready, no third-party audit yet. The security argument rests on test vectors and CT verifiers now, and on an independent third-party audit later.
Which is also why the feedback I'm after here isn't a security audit at all. It's the developer-using-crypto kind:
- Is the API useful and well-shaped for real use?
- Is the algorithm coverage sufficient?
- Are the supported targets the right ones?
- What packaging would make this genuinely usable for you?
- ...
If that's still not your cup of tea, fair enough. But it isn't slop, and it isn't an attempt to offload the hard part onto someone else.
Thanks again for engaging.