rscrypto v0.3.1 adds portable pure-Rust crypto with zero dependencies

Cryptography is one of the fastest ways to make a portable Rust project feel fragile, and rscrypto v0.3.1 goes straight after that problem. Announced on June 2, 2026, the release packages hashes, MACs, KDFs, AEADs, checksums, and public-key primitives into one feature-selected crate with zero default dependencies, no C libraries or FFI in the primitive stack, and support for no_std and WASM.

The pitch is not breadth for its own sake. rscrypto’s release materials say the stack covers SHA-2, SHA-3, BLAKE2, BLAKE3, CRC variants, HMAC, HKDF, PBKDF2, Argon2, scrypt, RSA, Ed25519, X25519, AES-GCM, AES-GCM-SIV, ChaCha20-Poly1305, XChaCha20-Poly1305, AEGIS-256, and Ascon-AEAD128. The GitHub release page describes it as a Rust crypto stack with zero default dependencies, while the README says the portable Rust backend is always present and SIMD plus assembly are only accelerators. It also says the primitive stack does not rely on OpenSSL, RustCrypto, dalek, blake3, or crc unless optional integration features are turned on.

That design came out of a familiar pain point in real projects. The author said the crate was motivated by supply-chain risk and by the way portability gaps show up once cryptography enters a codebase. In the Hacker News discussion, the same theme came through even more bluntly: the supply-chain risk was too high, and v0.3.1 was meant to be one feature-selected crate instead of a patchwork of dependencies. The release notes back up the portability claim with testing across Intel, AMD, AWS Graviton, IBM Z, POWER, and RISC-V, plus no_std targets including thumbv6m, wasm32, and x86_64-unknown-none.

The benchmark story is part of the case too. The README reports Linux CI at 1.61x fastest-external geomean, with 3,545 wins out of 5,832 runs and 5,210 wins or ties. That puts rscrypto in a different lane from the usual “pure Rust, therefore safer” pitch, because it is also trying to argue that a unified backend can stay competitive while keeping deployment control, binary size, and target coverage in view. The Embedded Rust Book’s no_std model explains why that matters: once standard-library assumptions stop fitting constrained targets, crypto is often where projects get stuck.

The comparison with established Rust crypto stacks sharpens the tradeoff. RustCrypto says it maintains dozens of pure-Rust crates and currently lists 39 repositories, but its independently versioned crates can create compatibility overhead. Rustls, meanwhile, still relies on providers based on aws-lc-rs and ring and supports custom providers, while aws-lc-rs itself uses FFI to invoke AWS-LC. Rscrypto’s bet is that embedded boards, WASM builds, and cross-platform side projects are better served by one portable Rust backend that is always there, with hardware acceleration layered on top only when the target can take it.