The readme has strong LLM smells. Was the code written by an LLM as well?

What is your experience with cryptographic engineering, in particular avoiding common implementation pitfalls that bite first-time implementers of cryptographic primitives?

Are the primitives tested against Wycheproof vectors, and proofed against the common implementation mistakes they document?

▲

tux3 2 days ago | parent | next [-]

Yeah, spot on. This is what the code looks like: https://github.com/loadingalias/rscrypto/blob/4e24772a54fef3...

Look at these section comments that LLMs love ("// ─── Rotation helpers ────")

Now you sometimes see these section comments in legacy codebases that have very long files. What you don't see people use is U+2500 BOX DRAWINGS LIGHT HORIZONTAL unicode characters padded out just right to look pretty. We humans have regular keyboards, but these AIs are trained to output emojis and pretty unicode.

	▲	LoadingALIAS 2 days ago \| parent [-]
		The documentation and to a large extent commenting, auditing, and almost every markdown file was likely generated with an LLM. Do not mistake that for competence or quality. This is a pre-v1 codebase. I'm looking for bench-methodology failures; I'm looking for API issues and/or code smells. I'm looking for ASM/SIMD weak points and/or testing issues. Over time, as I have the capacity, I will almost certainly clean up anything that's just not necessary. Having said that, if something feels clean and it was done by an LLM in my harness/workflow - I'm 100% happy to leave it. Please, dig into the code. Let me know what you see. Thanks.

▲

LoadingALIAS 2 days ago | parent | prev [-]

Yeah, all fair questions.

To address the LLM question - almost all MD files in the codebase were built around the codebase by an LLM. I simply don't have the time; this project is a side project and not my main squeeze. This is also a pre-v1 codebase; I will have time soon enough to address anything overly 'LLM' flavored.

My experience covers nearly two decades in one way or another. Having said that, I've never felt like I had the time, nor the need, for rscrypto. The last year was different; I genuinely needed this myself for my actual work. I have worked on rscrypto in part for a year. This isn't like a whimsical LLM codebase or some vibe coded junk.

I use LLMs in my workflows every single day and have for the better part of two-years; I gain more trust in them almost weekly, too. I feel like there isn't an engineer on Earth who can say otherwise and if there is... I'd probably argue with them against integrating LLMs into their tooling in some way.

Finally, the actual important question... not all primitives are tested against Wycheproof vectors yet. RSA - yes; the whole crate, not yet. Again, it's just a time thing. I've used official RFC/NIST vectors, RustCrypto/oracle differential tests, proptests, fuzz corpus replay, Miri where applicable, and backend-vs-portable equivalence tests to cover the rest of the codebase.

Also, “proofed” is too strong a word for test vectors, IMO. Wycheproof is regression evidence against known bug classes, not a proof of cryptographic correctness.

Nevertheless, it's a valid point and it's covered in my backlog as of like a month ago.