# Rust Users Forum
Post in the **announcements** category. The forum audience is more receptive to release announcements than HN, but it's also the most demanding on engineering substance: MSRV, edition, feature-flag shape, API quality, breaking-change policy, and whether the crate creates more fragmentation than value. Hype gets read as carelessness here.
Per [`case-studies.md`](case-studies.md):
- `crypto-bigint` earned trust by naming constant-time behavior, the audit context, `no_std` policy, and the unsupported-processor caveats up front.
- The original pure-Rust `sha2` post made a single load-bearing claim (no C code, builds where Rust builds) and held it.
- RustCrypto release announcements are careful about ecosystem impact and breaking changes.
The forum is the right place for API, feature-flag, unsafe/SIMD, and MSRV review. It is not the right place for "I just released a thing!!!" energy.
---
## Topic Title
```text
rscrypto v0.3 — pure-Rust crypto across six architecture families, zero default deps
```
Alternates if the first feels too long for the forum's title pane:
```text
rscrypto v0.3.0 — single-crate pure-Rust crypto stack, nine Linux runners
```
```text
ANN: rscrypto v0.3.0 — pure-Rust crypto with portable Rust as the byte-for-byte authority
```
---
## Post Body
````markdown
I published `rscrypto` v0.3.0 today.
- Repo: https://github.com/loadingalias/rscrypto
- Crates.io: https://crates.io/crates/rscrypto
- Docs.rs: https://docs.rs/rscrypto
- Benchmarks: https://github.com/loadingalias/rscrypto/blob/main/benchmark_results/OVERVIEW.md
- Migration guides: https://github.com/loadingalias/rscrypto/blob/main/docs/migration/README.md
`rscrypto` is a single-crate, feature-selectable cryptography stack: cryptographic and fast hashes, MACs, KDFs, password hashing, signatures, key exchange, AEADs, and the full CRC family. The motivating idea is that crypto should not be the place an otherwise portable Rust project stops being portable — different stack on the server, different answer on WASM, a quiet portable fallback the moment the target is not x86_64, and a dependency graph that grows every time you add a primitive.
So one crate. Leaf features (`sha2`, `aes-gcm`, `ed25519`, anything) for minimal builds; `full` for the toolbox.
```toml
[dependencies]
# minimal
rscrypto = { version = "0.3.0", default-features = false, features = ["sha2"] }
# or the whole stack
rscrypto = { version = "0.3.0", default-features = false, features = ["full"] }
```
**MSRV**: Rust 1.91.0. **Edition**: 2024. **`no_std`-first**: `default = ["std"]` and `std` implies `alloc`; `default-features = false` removes both, with `alloc` available as a separate opt-in. The portable Rust path is always present and is the byte-for-byte authority for every primitive — see the testing model below.
## Scope
| Cryptographic hashes | SHA-2 (224/256/384/512/512-256), SHA-3 (224/256/384/512), SHAKE128/256, cSHAKE256, BLAKE2b/2s, BLAKE3 (hash, keyed, derive-key, XOF), Ascon-Hash256, Ascon-Xof, Ascon-CXof |
| Fast (non-crypto) hashes | XXH3-64, XXH3-128, RapidHash 64/128 |
| Checksums | CRC-16 (CCITT, IBM), CRC-24 (OpenPGP), CRC-32 (ISO-HDLC), CRC-32C, CRC-64/XZ, CRC-64/NVMe |
| MACs / KDFs | HMAC-SHA-{256, 384, 512}, KMAC256, HKDF-SHA-{256, 384}, PBKDF2-HMAC-SHA-{256, 512} |
| Password hashing | Argon2 (id/d/i), scrypt, PHC-string encode + bounded-policy verify |
| Signatures / KEX | RSA, Ed25519, X25519 |
| AEADs | AES-256-GCM, AES-256-GCM-SIV, ChaCha20-Poly1305, XChaCha20-Poly1305, AEGIS-256, Ascon-AEAD128 |
Zero default dependencies. The `full` primitive stack does not pull OpenSSL, C FFI, RustCrypto, dalek, blake3, or any `crc-*` crate. Optional integration features (`getrandom`, `serde`, `rayon`) stay out of the dependency graph until you ask for them.
## What's different
| Many single-primitive crates | One feature-selected crate |
| Per-crate target assumptions | One platform matrix |
| Native-library risk in some stacks | No C libraries in the primitive stack |
| Per-primitive dispatch behavior | One dispatch model: compile-time `target_feature` → runtime detection (cached in `platform::caps()`) → portable fallback |
| API glue around generic traits | Typed handles for common combinations (e.g., `HmacSha256` is a concrete type, not `Hmac<Sha256>`) |
## Platform matrix
CI benchmarks run on nine Linux runners — Intel Sapphire Rapids and Ice Lake, AMD Zen4 and Zen5, AWS Graviton3 and Graviton4, IBM Z (s390x), IBM POWER10 (ppc64le), RISE RISC-V. **IBM** opened POWER10 and IBM Z runner access; **RISE** opened RISC-V. Without those partnerships, the s390x, ppc64le, and riscv64 backends would not exist for a single-maintainer crate.
Tested `no_std` build targets: `thumbv6m-none-eabi`, `riscv32imac-unknown-none-elf`, `aarch64-unknown-none`, `x86_64-unknown-none`, `wasm32-unknown-unknown`, `wasm32-wasip1`. The portable fallback is always available, so any target Rust supports will run `rscrypto` correctly — only the SIMD/ASM acceleration is gated to the architectures the matrix covers.
## Testing model
- **Portable Rust as the byte-for-byte authority.** Every SIMD or ASM kernel is differential-tested against the portable path on every CI run. Mismatch fails the build.
- **Official vectors** for every primitive that has them.
- **Differential oracles** against the established external crates listed above.
- **Constant-time MAC / AEAD / signature verification** via `ct::constant_time_eq` with a `black_box` barrier — no early exit, no branch on secret bytes.
- **Opaque `VerificationError`.** AEAD `decrypt` paths wipe the output buffer before returning the error.
- **Zeroize on drop** for every secret-key, shared-secret, and intermediate-secret type.
- **Strict arithmetic** for counters, lengths, indices, offsets. Release builds keep `overflow-checks = true`.
- **Miri** clean on the portable backends.
- **Continuous fuzzing** via libFuzzer on parsers (PHC strings, encoded params), streaming APIs, and differential oracles. Weekly CI corpus replay.
- **`cargo deny` and `cargo audit`** weekly.
- **`portable-only` feature flag** forces every dispatcher to the constant-time portable backend and bypasses runtime SIMD invocation, for FIPS / DO-178C / ISO 26262 / IEC 62443 deployment modes.
## Performance
On 5,832 fastest-external Linux CI comparisons against the strongest matched Rust baseline per case, `rscrypto` wins 3,545, wins-or-ties 5,210, and has a 1.61× geomean. On the Apple Silicon MBP M1 macOS/aarch64 full run, it wins 235 of 463, wins-or-ties 450 of 463, and has a 1.25× geomean. Strongest categories:
- Checksums 5.03× geomean
- SHA-3 / SHAKE 2.15× / 1.86× vs RustCrypto `sha3`
- BLAKE3 large inputs 2.31× vs the `blake3` crate (≥ 64 KiB, one-shot/keyed/derive-key)
- AEAD 1.57× across RustCrypto AEADs, `aegis`, `ring`, and `aws-lc-rs`
- RSA import plus verification 1.32× with 75 wins out of 99 RSA comparisons; verification-only 0.98×
- Apple Silicon MBP M1: checksums 2.76×, AEAD 1.47×, RSA import plus verification 1.45×, RSA verification-only 1.19×, BLAKE3 ≥64 KiB 1.80×
Full per-platform results, including every tie and loss, are in the overview link above. It is not universally faster — PBKDF2-SHA256 setup, X25519 DH, RSA verification on Arm/RISC-V, and small-message AEAD rows are still pressure points. The Apple Silicon full run also shows BLAKE3 64 KiB losses, HMAC-SHA256 bulk pressure, empty-message ChaCha20-Poly1305 overhead, and SHA3-256 streaming losses. Hiding the losses would make the data useless.
## Caveats (up front, not below the fold)
- **Not a FIPS 140-3 validated module.** `rscrypto` provides FIPS-aligned primitives; validation requires defining the module boundary, operational environment, self-tests, documentation, and CMVP lab review. That work is tracked in `docs/compliance.md`.
- **Not a TLS stack.** No record-layer, no handshake, no certificate handling.
- **Not a key store.** Use the OS facility for key custody.
- **No third-party audit yet.** A pre-1.0 audit is on the roadmap.
- **The 0.3 line is pre-1.0.** Breaking changes are still possible if review surfaces a better API shape. The `0.3.x` release line will preserve compatibility within itself; `0.3.0` will be where breaking work lands if it lands at all.
## What I'd most value
The forum audience is the most useful for the kinds of feedback I want now:
- **API shape mistakes** — typed handles vs. generic traits, infallible signatures where they're correct, naming consistency across families.
- **Feature-flag splits** that are too broad or too narrow.
- **Unsafe / SIMD soundness review.** Every SIMD or ASM kernel sits behind a `// SAFETY:` block; eyes on those (especially the s390x VGFM, ppc64le VSX, and riscv64 V/Zbc paths) are welcome.
- **MSRV policy review** — currently 1.91.0, treated as a minor breaking change to bump.
- **Migration blockers** from RustCrypto, `blake3`, `crc-fast`, `crc32fast`. Migration starters: https://github.com/loadingalias/rscrypto/blob/main/docs/migration/README.md
- **Anything in the docs the code doesn't back up.**
For sensitive findings, GitHub's Private Vulnerability Reporting is enabled — acknowledgment within 48 hours.
````
---
## Follow-Up Comment (post yourself, ~24 hours after the topic)
```markdown
Quick update on the threads here so far:
- [list of issues filed in response to specific feedback, with #N links]
- [list of API points that came up and where they stand for v0.3]
- [anything that turned out to be a documentation gap and the commit/PR that fixed it]
Thanks for the careful reads. Next planned forum post is a longer one about [migration / unsafe review / portable-only], but I want this thread to settle first.
```
The follow-up comment matters because forum threads age the longest. A reader arriving in six months should see that the OP engaged with the feedback, not just dropped a release announcement and left.
---
## Tone Rules
- Say **"published"** or **"released"**, never "launched."
- Mention **MSRV** and **edition** in the body, not in a footnote.
- Invite review explicitly, by category (API, unsafe, benchmark, migration), not as a vague "looking for feedback."
- Caveats appear before the request, not after.
- No emoji. None. Not even one. The forum's typography setting amplifies them and they look out of place.
- No exclamation marks. None.
- "I" is the right pronoun for a single maintainer. Don't ghost-write yourself in the third person.
---
## What Not to Do
- Do not post "ANN: " on the title line and "ANNOUNCEMENT" again at the top of the body. The category does that work.
- Do not edit the body materially after posting; small typo fixes are fine.
- Do not paste the HN or DEV copy here. They're calibrated for different audiences.
- Do not respond to a critique with marketing copy. If the question is technical, the answer is technical or it's an issue link, not "you should try it."
- Do not bump the topic with a "any feedback?" reply if it goes quiet. Forum decay is normal; quiet is not failure.