I published rscrypto v0.3.1 last night and I feel it's finally time for the Rust community to review it before the API gets harder to change.

TLDR
rscrypto is a single feature-selected crypto/hash/checksum crate with zero default deps, no C-libs and/or FFI in the primitive stack, no_std/WASM support, portable Rust fallbacks, and hardware acceleration where the target can actually use it.

• crates.io
• Github
• docs.rs
• Benches, including the losses.
• Migration Support, including RustCrypto, ring, aws-lc, and more.
• Contact me on X or open an Issue on Github

The reason I built this is simple: crypto is often where an otherwise portable Rust project stops being portable. We end up with per-primitive crates, different API conventions, target gaps, native library questions, and performance surprises when you leave the usual x86_64 server path. This was true in my own codebase, which is the inspiration for rscrypto... removing the reliance on C-libs alone was like a weight off my shoulders.

Also, I feel strongly about security; crypto stacks aren't the place to play 'supply-chain roulette' considering the current landscape.

[dependencies]
# one primitive, no_std
rscrypto = { version = "0.3.1", default-features = false, features = ["sha2"] }

# or the full primitive stack
rscrypto = { version = "0.3.1", features = ["full", "getrandom"] }

MSRV is Rust 1.91.0. default = ["std"]; default-features = false gives a no_std build, with alloc and getrandom as explicit opt-ins.

Scope

full includes:

• Hashes: SHA-2, SHA-3, SHAKE, cSHAKE256, BLAKE2b/2s, BLAKE3, Ascon-Hash/XOF/CXOF.
• Fast Hashes: XXH3-64/128, RapidHash 64/128
• Checksums: CRC-16, CRC-24, CRC-32, CRC-32C, CRC-64/XZ, CRC-64/NVMe.
• MACs/KDFs/password hashing: HMAC-SHA-2, KMAC256, HKDF-SHA-2, PBKDF2-HMAC-SHA-2, Argon2d/i/id, scrypt, PHC strings.
• Public-key primitives: RSA, Ed25519, X25519.
• AEADs: AES-128-GCM, AES-256-GCM, AES-128-GCM-SIV, AES-256-GCM-SIV, ChaCha20-Poly1305, XChaCha20-Poly1305, AEGIS-256, Ascon-AEAD128.

The primitive stack does not depend on OpenSSL, C FFI, RustCrypto, dalek/curve, blake3, or crc-* crates. Optional integration features such as serde, rayon, and getrandom stay out until enabled.

Evidence

The current benchmark evidence is:

• Linux Runners: Intel Sapphire Rapids, Intel Ice Lake, AMD Zen4, AMD Zen5, AWS Graviton3, AWS Graviton4, IBM Z/s390x, IBM POWER10/ppc64le, and RISE RISC-V.
• macOS: Apple Silicon MBP M1, which is my local dev machine

no_std build targets in CI: thumbv6m-none-eabi, riscv32imac-unknown-none-elf, aarch64-unknown-none, x86_64-unknown-none, wasm32-unknown-unknown, and wasm32-wasip1.

The portable Rust implementation is always present. SIMD/ASM paths are accelerators and are supposed to be byte-identical to the portable path.

Perf Snapshot

Ratios are fastest matched external Rust baseline time divided by rscrypto time, so higher is better.

• Linux CI fastest-external: 3,545 wins and 5,210 wins-or-ties out of 5,832 comparisons; 1.61x geomean across the stack.
• Apple Silicon MBP M1 fastest-external: 235 wins and 450 wins-or-ties out of 463 comparisons; 1.25x geomean.
• BLAKE3 large inputs, >=64 KiB: 2.31x Linux CI geomean vs the blake3 crate; 1.80x on the MBP M1 run.
• AEAD: 1.57x Linux CI geomean; 1.47x on MBP M1.
• Checksums: 5.03x Linux CI geomean; 2.76x on MBP M1.

It is not universally faster, but it's VERY close. The 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 overview lists the losses next to the wins. This will improve with time.

Caveats

• Not FIPS 140-3 validated
• Not a TLS stack.
• Not a key store.
• No third-party audit yet, but I desperately desire one.
• Pre-1.0. I will preserve compatibility inside the 0.3.x line, but API changes are still possible in the next minor if review finds a better shape.

Please Review The Following

• API shape: typed handles, concrete aliases, fallible vs infallible constructors, naming consistency.
• Feature flags: whether the leaf/group split is too narrow or too broad.
• no_std/WASM assumptions.
• Unsafe/SIMD/ASM soundness, especially IBM Z, POWER10, RISC-V, and Apple Silicon paths.
• Benchmark methodology and missing workloads.
• Migration blockers from RustCrypto, blake3, crc-fast, and crc32fast.

For sensitive findings, GitHub Private Vulnerability Reporting is enabled. For public API, docs, benchmark, or portability feedback, issues and PRs are welcome.

1 post - 1 participant

Read full topic