I've built rscrypto because crypto kept being where my Rust database stopped being portable: different stack on the server, different target story on WASM, different answer on RISC-V/POWER/IBM Z, and a different audit surface every time I added a primitive. The supply chain risk, given the landscape we're in today, was too high.

v0.3.1 is one feature-selected crate. Leaf features when you need one primitive (`sha2`, `rsa`, `aes-gcm`, `ed25519`, etc.) or `full` for the stack. Scope includes SHA-2/3, SHAKE, cSHAKE256, BLAKE2, BLAKE3, Ascon hash/XOF, XXH3, RapidHash, CRCs, HMAC, KMAC256, HKDF, PBKDF2, Argon2, scrypt, PHC strings, RSA, Ed25519, X25519, AES-128/256-GCM, AES-128/256-GCM-SIV, ChaCha20-Poly1305, XChaCha20-Poly1305, AEGIS-256, and Ascon-AEAD128.

The primitive stack has zero default deps and no C-libs or FFI. Optional `getrandom`, `serde`, and `rayon` features stay out until enabled.

The current bench evidence is across nine Linux runners (Intel Sapphire Rapids, Intel Ice Lake, AMD Zen4, AMD Zen5, Graviton3, Graviton4, IBM Z/s390x, IBM POWER10/ppc64le, RISE RISC-V) and my local Apple MBP M1.

Linux vs. fastest-external: 3,545 wins and 5,210 wins-or-ties out of 5,832 comparisons, 1.61x geomean.

MBP M1 vs fastest-external: 235 wins and 450 wins-or-ties out of 463 comparisons, 1.25x geomean.

BLAKE3 large inputs (`>=64 KiB`) are 2.31x geomean improvement across Linux vs the official `blake3` crate and 1.80x on MBP M1.

While it's not universally faster - it's incredibly close. Current weak spots include PBKDF2-SHA256 setup at `iters=1`, X25519 DH, RSA verification on Arm/RISC-V, small-message AEAD rows, MBP M1 BLAKE3 64 KiB rows, HMAC-SHA256 bulk pressure against `aws-lc-rs`, and SHA3-256 streaming on Apple Silicon. The `./benchmark_results/OVERVIEW.md` lists the losses next to the wins in more detail.

Trust, Testing, Etc: portable Rust is the byte-for-byte authority. SIMD/ASM paths are accelerators and are differential tested against the portable path. MAC, AEAD, and signature comparisons are constant-time. Secret-bearing types zeroize on drop. I've got a pretty thorough Miri and Fuzzer testing gate setup, too. The RSA impl has it's own CI gate. Codecov = 73.06, fuzzing included.

This is not FIPS 140-3 validated, not a TLS stack, not a key store, and not third-party audited yet. I am genuinely interested in a third-party audit and would LOVE to plan for FIPS 140-3 validation, but it's just out of my reach right now.

The codebase/lib is obviously pre-v1 and I'm asking for public review while API changes are still relatively cheap.

Repo: https://github.com/loadingalias/rscrypto

Crate: https://crates.io/crates/rscrypto

Benches: https://github.com/loadingalias/rscrypto/blob/main/benchmark...

Migration Guides: https://github.com/loadingalias/rscrypto/blob/main/docs/migr...

Me: https://x.com/loadingalias

If you're testing, benching, etc. and happen to stumble across inconsistencies, vulnerabilities, etc. - please just reach out directly via 'X' or use Github's Vulnerability Reporting. There are a decent number of people already using the library.

Also, the 'fastest-external' competitors for perf comparisons are almost always one of the following: aws-lc-rs, ring, RustCrypto, dryoc, OpenSSL, Blake3 and/or one of the many 'crc-fast/fast-crc' crate variations. I benched these external crates against eachother in the beginning to trace the most performant before hunting inefficiency and cutting out any external deps/c-libs. So, if the benches show a 2x geomean over Blake3... that means it's over the fastest implementation of Blake3 I could find and bench publicly.

Hi @LoadingAlias,

> Constant-time MAC, AEAD, and signature verification.

That sounds suspiciously incomplete to me.

Which cryptographic algorithms in the library are currently not implemented in constant time?

Where did the speedup come from? How where these optimizations achieved?

What motivated you to write the library? Why not contribute to existing rust crypto libraries instead? How is the work financed?

What peer review strategy are you following with the library? Who else but yourself has verified this code?

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?