rscrypto: High-Performance Pure-Rust Cryptographic Primitive Stack
rscrypto is a single-dependency primitive stack designed for projects requiring high execution speed, small binary sizes, and strict deployment control without relying on C libraries, OpenSSL, or system dependencies. It provides a comprehensive suite of cryptographic tools—including RSA, Ed25519, X25519, AEADs, hashes, and KDFs—with a portable Rust backend and optional SIMD/ASM acceleration.
Performance Benchmarks
rscrypto demonstrates significant performance advantages over the fastest matched Rust baselines across multiple architectures. In Linux CI environments, the library achieved a 1.61x geomean speedup, with 3,545 wins and 5,210 wins-or-ties out of 5,832 matched comparisons. On Apple Silicon (MBP M1), it achieved a 1.25x geomean speedup, with 235 wins and 450 wins-or-ties out of 463 pairs.
Key Performance Metrics
| Area | Linux CI Geomean | Apple Silicon Geomean |
|---|---|---|
| Checksums | 5.03x | 2.76x |
| BLAKE3 (>=64 KiB) | 2.31x | 1.80x |
| AEAD | 1.57x | 1.47x |
| RSA Import + Verify | 1.32x | 1.45x |
| SHA-3 / SHAKE | 2.15x / 1.86x | 0.94x / 1.32x |
While generally faster, the author notes specific "weak spots" where the library is slightly slower than competitors, including PBKDF2-SHA256 (iters=1), X25519 Diffie-Hellman, and RSA-4096 verification on certain platforms.
Feature Set and Capabilities
rscrypto consolidates multiple cryptographic families into one coherent stack to avoid the complexity of managing numerous disparate crates. The library is designed for no_std targets, making it suitable for server, CLI, embedded, bare-metal, and WASM builds.
Included Primitives
- Cryptographic Hashes: SHA-2, SHA-3, SHAKE, cSHAKE256, BLAKE2, BLAKE3, and Ascon-Hash/XOF/CXOF.
- MACs and KDFs: HMAC-SHA-2, KMAC256, HKDF-SHA-2, and PBKDF2-HMAC-SHA-2.
- Password Hashing: Argon2d/i/id, scrypt, and PHC string encoding/verification.
- Public-Key Primitives: Ed25519 signatures, X25519 key exchange, and full RSA support (signing, verification, OAEP, RSAES-PKCS1-v1_5, and FIPS 186-5 A.1.3 probable-prime key generation).
- AEAD Encryption: AES-128/256-GCM, AES-128/256-GCM-SIV, ChaCha20-Poly1305, XChaCha20-Poly1305, AEGIS-256, and Ascon-AEAD128.
- Checksums and Non-Crypto Hashes: CRC-16/24/32/32C/64, XXH3-64/128, and RapidHash 64/128.
Architecture and Portability
The library uses a portable Rust implementation as the source of truth, utilizing ISA-specific kernels only as accelerators. This ensures that the library remains functional across all targets while maximizing performance on supported hardware.
Hardware Acceleration Support
- x86 / x86_64: SSE4.2, AVX2, AVX-512, AES-NI, SHA-NI, VAES, VPCLMULQDQ.
- Arm / AArch64 / Apple Silicon: NEON, AES, PMULL, SHA2, SHA3, SVE2-PMULL.
- IBM Z / POWER: CPACF, MSA, VGFM, and POWER8/9/10 vector extensions.
- RISC-V: RVV, Zbc, Zvkned, Zvbc.
- WASM: SIMD128 support with portable fallbacks.
Security Implementation
rscrypto incorporates several security hygiene practices into its API and build process. These include constant-time verification for MACs, AEADs, and signatures, as well as secret-bearing types that zeroize on drop and mask Debug output.
To ensure correctness, the project employs:
- Differential testing between portable and accelerated backends.
- Official test vectors and fuzz corpus replay.
- Miri and
cargo auditintegration in CI. - Opaque verification errors to prevent side-channel leaks.
Community Discussion and Critique
The library has faced scrutiny from the cryptography community regarding its security claims and development process. Notably, Karolin Varner (designer of the Rosenpass Protocol) expressed strong concerns about the library's readiness for production use.
"I would strongly advise anyone against using this library for the following reasons: Lack of third-party reviews/existing review processes... Lack of complete constant-time cryptography support... The author's own insistence that this pre-v1 code... is especially alarming since it's not found in the README."
Varner specifically questioned the author's claim of constant-time MACs while not claiming constant-time hashes, noting that since MACs are often implemented via hashes, this is a contradiction. She also suggested that the reported performance gains might stem from a lack of strict constant-time implementations, which typically incur a performance penalty.
In response, the author clarified that the library is indeed pre-v1 and is seeking public review. They emphasized that the portable Rust path serves as the byte-for-byte authority and that they are interested in future third-party audits and FIPS 140-3 validation.