Karolin, I’ll answer this directly, and try to stay on track, because several claims here are materially wrong.

First things first, I am not claiming I've had any third-party audit; I'm not claiming I've been FIPS validated, or telling anyone “use this blindly in high-assurance production.” If that is your bar, then yes: do not use rscrypto yet. That is a fair warning... and it's plastered everywhere. I almost feel like you didn't read the codebase, the thread here, etc.

Now, to your constant-time criticism - it's just not correct. It's wrong. It's misleading. It shouldn't come from someone leading Rosenpass.

“Not a global constant-time claim” does not mean “secret-bearing cryptographic ops branch on secrets.” I've said this twice now - verbatim. It means I am refusing to make a fake blanket claim over APIs where constant-time behavior is either irrelevant, impossible, or the wrong security property.

DER parsing is not supposed to be constant-time over DER structure. PHC string decoding is not supposed to be constant-time over ASCII syntax. OS randomness is not a constant-time primitive. RSA public verification/encryption operates on public inputs. Rejection of public length/shape before entering a primitive boundary is NOT a secret-dependent timing leak. Argon2d intentionally has data-dependent memory access; treating it as a blanket CT primitive would be wrong - it's a lie at that point.

That list was a boundary, Karolin, not an admission of insecure primitives.

The MAC/hash point is also mixing categories. A MAC verification claim is about the keyed construction and verification surface: no secret-dependent behavior in the keyed path that matters for the construction, opaque failure, and constant-time tag comparison. An unkeyed hash API as a whole does not get the same global claim because message length, streaming shape, finalization shape, feature-dispatched kernels, and non-crypto hash/checksum APIs are public-input machinery. “HMAC uses a hash” does not imply “the entire hash API must be globally constant-time under every possible use.”

On “algo/profile negotiation”: this is not TLS-style negotiation. It is closed protocol identifier mapping for RSA profiles: JWT/COSE/TLS/X.509 identifiers are parsed into EXPLICIT supported profile enums, and unsupported/confused algos are rejected. If the word “negotiation” suggested downgrade-prone protocol behavior, I should fix the language, sure, but the feature is not an open negotiation mechanism.

With respect to the perf, if you believe a benchmark win comes from a specific missing constant-time property, name the primitive, input class, backend, and compared impl. “It might be faster because it is insecure” is not evidence... it's negativity and hyperbole.

Also, every single line of this codebase is my responsibility. My usage of an LLM is not a substitute for review, tests, vectors, fuzzing, Miri, and/or a third-party audit. If you're insinuating that using an LLM today is a vulnerability report - I'm afraid you're falling behind the best engineers in the world and are sorely mistaken.

Finally, and this is the one that really gets under my skin, which is likely your goal given your very public history of such... my putting code in public doesn't force cryptographers to review it. It invites scrutiny. If there is duplication that materially increases audit cost, point to it and I will remove or justify it. If there is a side channel, GIVE ME THE PATH and I will treat it as a security issue. But “do not publish until the community has reviewed it” is backwards: review cannot happen against code that is not visible. You're plastered all across the Internet championing this exact maxim, are you not? Did I not read an interview this morning where you went on about the importance of OSS crypto?

Please, take some time to review the codebase or don't; that's up to you... but don't come in here and trash my work improving and unifying well known primitives. Also, this isn't a whimsical codebase vibe coded by Claude overnight. This is a year of my life reading, understanding, and improving the inefficiencies in primitives I've used for years.

The entire point of a pre-v1 review by the community is the same exact thing OSS engineers/contributors have done for decades. I'm looking for the community to point out glaring issues, errors, API shapes, code smells, etc. You came in here with a bunch of incorrect claims and emotion. This codebase isn't perfect, but I assure you - it will be, and it will lead Rust by default becasue there simple will not be a better option.

Happy to talk one on one, or we could put something together where others have a chance to chime in. Either way, have a good one.