# Reddit
Primary target: **r/rust**. One high-effort post, then live in the comments. Do not cross-post the same copy to a dozen subreddits — Reddit's anti-spam guidance flags it and r/rust regulars will notice and downvote.
What r/rust actually rewards (per [`case-studies.md`](case-studies.md) — RustCrypto, BLAKE3, pure-Rust SHA-2, `crypto-bigint`):
- **Specific Rust relevance up top.** Not "I made a thing"; "I made a Rust crate that does X for Y reason."
- **Code blocks early.** Installation is a `Cargo.toml` snippet by paragraph two.
- **Honesty about limits.** Audit status, MSRV, breaking-change policy — named before someone has to ask.
- **The post is useful even if you don't click through.** A reader who only reads the body should learn something concrete (the feature shape, the trade, the migration story).
Things r/rust does **not** reward: superlatives without numbers, "drop-in replacement" claims, marketing tone, multi-emoji titles, and asking for stars.
---
## Title
```text
rscrypto v0.3.0 — pure-Rust crypto, Linux CI + Apple Silicon benches, zero default deps
```
This is 130 characters — long, but r/rust tolerates long titles when they're load-bearing. Every clause does work:
- `rscrypto v0.3.0` — searchable.
- `pure-Rust crypto` — flags the audience instantly.
- `nine Linux runners` — the unusual thing, without overstating architecture count.
- `(zero default deps, Linux CI + Apple Silicon benches…)` — the number a reader can verify without overfitting the title.
If you prefer a shorter form:
```text
rscrypto v0.3.0 — pure-Rust crypto stack, nine Linux runners, public benchmarks
```
**Flair**: `announcement` if the subreddit's flair list has it. Otherwise no flair.
---
## Post Body
```markdown
I published `rscrypto` v0.3.0:
- Repo: https://github.com/loadingalias/rscrypto
- Crates.io: https://crates.io/crates/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
I built it because crypto kept being the place my Rust services stopped being portable. Different stack on the server, different answer on WASM, a quiet portable fallback the moment the target wasn't x86_64, and a dependency graph that grew every time I added a primitive. I wanted one crate I could shrink to one feature or expand to the whole toolbox without losing hardware acceleration or auditability.
## What it is
A single-crate, feature-selectable crypto stack:
- **Cryptographic hashes**: SHA-2, SHA-3, SHAKE, cSHAKE, BLAKE2b/2s, BLAKE3 (hash, keyed, derive-key, XOF), Ascon-Hash256, Ascon-Xof, Ascon-CXof
- **Fast hashes**: XXH3-64, XXH3-128, RapidHash 64/128
- **Checksums**: CRC-16, CRC-24 (OpenPGP), CRC-32, CRC-32C, CRC-64/XZ, CRC-64/NVMe
- **MACs / KDFs**: HMAC-SHA-{256, 384, 512}, KMAC256, HKDF, PBKDF2
- **Password hashing**: Argon2 (id/d/i), scrypt, PHC strings with bounded-policy verify
- **Signatures / KEX**: RSA, Ed25519, X25519
- **AEADs**: AES-256-GCM, AES-256-GCM-SIV, ChaCha20-Poly1305, XChaCha20-Poly1305, AEGIS-256, Ascon-AEAD128
```toml
# One primitive
rscrypto = { version = "0.3.0", default-features = false, features = ["sha2"] }
# Or the whole toolbox
rscrypto = { version = "0.3.0", default-features = false, features = ["full"] }
```
Zero default dependencies. `getrandom`, `serde`, and `rayon` are opt-in. `full` does not pull OpenSSL, C FFI, RustCrypto, dalek, blake3, or crc-* crates.
MSRV is Rust 1.91.0, edition 2024. `no_std` first; `default = ["std"]` (which implies `alloc`).
## What's different
| Many single-primitive crypto crates | One feature-selected crate |
| Per-crate platform 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 → runtime → portable fallback) |
| x86_64 / aarch64 first; everything else later | RISC-V, IBM Z, POWER10, WASM, no_std are scope, not afterthoughts |
## 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.
## How fast
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.61x 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.25x geomean**. Strongest categories:
- **Checksums**: 5.03x geomean across Linux CI fastest-external comparisons.
- **SHA-3 / SHAKE**: 2.15x / 1.86x geomean vs RustCrypto `sha3`.
- **BLAKE3**: 2.31x geomean vs the `blake3` crate for one-shot/keyed/derive-key inputs ≥64 KiB.
- **AEAD**: 1.57x geomean across RustCrypto AEADs, `aegis`, `ring`, and `aws-lc-rs`; GCM-SIV, XChaCha20-Poly1305, AEGIS-256, and IBM Z are the strongest areas.
- **RSA**: 1.32x geomean and 75 wins out of 99 RSA comparisons for import plus verification, but verification-only is 0.98x.
- **Apple Silicon**: checksums 2.76x, AEAD 1.47x, RSA import plus verification 1.45x, RSA verification-only 1.19x, and BLAKE3 ≥64 KiB 1.80x fastest-external geomean.
It is not universally faster. PBKDF2-SHA256 at `iters=1` is 0.81x, X25519 DH is 0.92x, RSA-4096 verification is 0.94x, and small-message AEAD rows still lose on Linux CI. Apple Silicon adds full-corpus pressure in BLAKE3 64 KiB rows, HMAC-SHA256 bulk rows against `aws-lc-rs`, empty-message ChaCha20-Poly1305 rows, and SHA3-256 streaming rows. Every tie and loss is in the overview alongside every win — hiding them would make the data useless.
## How I keep myself honest
- The portable Rust path is the byte-for-byte authority. Every SIMD / ASM kernel is differential-tested against it on every CI run; mismatch fails the build.
- Three-tier dispatch: compile-time `#[cfg(target_feature)]` → runtime detection (cached in `platform::caps()`) → portable fallback. The fallback is always present.
- Constant-time MAC / AEAD / signature comparison via `ct::constant_time_eq` with a `black_box` barrier — no early exit, no branch on secret bytes.
- Zeroize-on-drop for every secret-key, shared-secret, and intermediate-secret type (volatile writes plus a compiler fence).
- Opaque `VerificationError`. AEAD `decrypt` paths wipe the output buffer before returning the error.
- `strict_*` arithmetic for counters, lengths, indices, offsets. Release builds keep `overflow-checks = true`.
- Miri-clean on the portable backends. Continuous libFuzzer on parsers and streaming. Weekly `cargo deny` and `cargo audit`.
- A `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.
## What this is not
- **Not FIPS 140-3 validated.** `rscrypto` provides FIPS-aligned primitives but is not a validated module.
- **Not a TLS stack.** No record-layer, no handshake, no certificate handling.
- **Not a key store.** Use the OS facility for key custody.
- **Not a finalized API.** The 0.3 line is pre-1.0, so breaking changes are still possible if review surfaces a better shape.
## What I'm asking for
The most useful feedback right now:
- API shape mistakes that will block adoption.
- `unsafe` / SIMD soundness — every SIMD or ASM kernel sits behind a `// SAFETY:` block; eyes on those are welcome.
- Benchmark methodology criticism — the CI workflow lives in `.github/workflows/bench.yaml`; raw Criterion outputs are checked into `benchmark_results/<date>/<os>/<arch>/`.
- Migration blockers from RustCrypto, `blake3`, `crc-fast`, `crc32fast`. Migration starters: https://github.com/loadingalias/rscrypto/blob/main/docs/migration/README.md
- Anything I've claimed in the docs that the code doesn't back up.
For sensitive findings, GitHub's Private Vulnerability Reporting is enabled — acknowledgment within 48 hours.
```
---
## Pre-Prepared Replies
### "Why another crypto crate?"
```markdown
Fair question. The value isn't that Rust lacks primitives; the established crates are excellent and I use them as differential oracles in CI. The architectural reason this exists as one crate: a single feature-selectable dependency, one dispatch model, one feature matrix, one error/security model, no mandatory external crate stack for `full`, and a platform matrix that treats RISC-V / IBM Z / POWER10 / WASM / no_std as scope rather than afterthoughts.
That's a different tradeoff for users who want the whole toolbox in one auditable dependency, not a fragmentation play.
```
### "Are you a security expert?"
```markdown
No. I'm a Rust engineer who needed this and built it carefully. That's why the trust model is "portable Rust is the byte-for-byte authority, every SIMD/ASM kernel is differential-tested against it on every CI run, official vectors, fuzz, Miri, opaque verification errors, zeroize-on-drop" rather than "trust me." It's also why the 0.3 line is asking for hard public review now — including from people more qualified than I am — instead of after the crate is embedded somewhere.
Pre-1.0 audit is on the roadmap. Until then, every claim in the docs has source code or test code I'd rather you read than take on faith.
```
### "Have you been audited?"
```markdown
Not yet. A third-party audit is on the roadmap before 1.0. The crate is in the 0.3 line specifically so the community can review it before it solidifies. Until the audit lands, the trust model is everything I named above plus the tests in `tests/` and `fuzz/` — which I'd rather have someone read critically than handwave around.
```
### "Drop-in for RustCrypto?"
```markdown
No. The APIs are intentionally not identical — `rscrypto` uses typed handles for common combinations (e.g., `HmacSha256` is a concrete type rather than `Hmac<Sha256>`) and infallible signatures where the input shape allows. Migration starters are in `docs/migration/README.md`; most one-line replacements work, but you should expect a small surface diff per primitive.
If you want literal drop-in, RustCrypto's per-primitive crates are the answer.
```
### "Where do I see the SIMD code?"
```markdown
Each algorithm family lives under `src/<family>/<alg>/<arch>.rs` — e.g., `src/hashes/crypto/blake3/x86_64.rs`. SIMD intrinsics are wrapped in `// SAFETY:` blocks with the invariants listed; the runtime detection that gates them is in `src/platform/`. The dispatch model is documented in `docs/architecture.md`. If you want a guided tour of one specific kernel, name it and I'll walk you through it.
```
### "What about post-quantum?"
```markdown
On the roadmap. ML-DSA (FIPS 204) and ML-KEM (FIPS 203) are next, with hybrid-mode helpers for transitioning from classical Ed25519 / X25519. Aim is to have them landed before 1.0. If you have specific use cases or wire-format expectations, an issue with that context shapes how I prioritize.
```
### "no_std support?"
```markdown
Yes — `no_std` first. `default = ["std"]` and `std` implies `alloc`, but `default-features = false` removes both. Add `alloc` back for the heap-output APIs. Tested no_std 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.
```
### "Why MSRV 1.91 and not pinned latest?"
```markdown
1.91 is the lowest stable I can hold while keeping the strict-arithmetic surface and edition 2024 features the design depends on. Bumping the MSRV is treated as a minor breaking change; it's tracked alongside language feature stabilization (e.g., `cfg_select!` in 1.95 is currently behind a polyfill comment that lifts when MSRV moves).
```
---
## Other Subreddits
Use only if you already participate there or have written copy specifically for that community. Generic cross-posting reads as spam regardless of post quality.
| `r/rust` | Main release announcement | **Yes**, one post. |
| `r/programming` | Long-form launch article (DEV / GitHub Discussion) | Maybe — only if you have an article worth linking, never crates.io. |
| `r/crypto` | Cryptographic review request | **Risky** — open framing should be "asking for review," never "I made the fastest." Lead with security model, not speedup. |
| `r/embedded` | `no_std` + portable-only + target coverage | Good — needs embedded-specific copy emphasizing `thumbv6m`, `riscv32imac`, no allocator assumptions. |
| `r/WebAssembly` | WASM/WASI portability + no C libs | Only with WASM-tailored copy, including a runnable example. |
| `r/RISCV` | RISE RISC-V data and Zbc/V usage | Good — frame the post as "RISC-V is a first-class benchmark target" with the benchmark numbers and the gratitude to RISE. |
| `r/devops` | Supply-chain / zero-default-deps angle | Weak unless tied to reproducible builds or a specific compliance scenario. |
If you post to any of these, do it on a different day — same-day cross-posting flags Reddit's spam heuristics.
---
## Posting Mechanics
- **Submit yourself, from your account.** No alts. r/rust mods read poster history.
- **Block out 90 minutes after posting** to reply. Reddit's algorithm gives early-engagement posts more visibility, and r/rust readers expect the OP to be present.
- **Reply to every comment in the first hour**, even one-line ones. Threaded reply chains push the post higher.
- **Do not delete and repost.** A failed post can be left to fade; a repost from the same account inside 24 hours gets flagged.
- **Do not ask for upvotes.** Reddit's spam policy flags this and the audience will downvote it.
- **Do not say "humbly," "blazing fast," or "we'd love your feedback."** Plain language only.
---
## What Not to Do
- Do not post the same link to many communities on the same day.
- Do not put "canonical" anywhere in the title or body.
- Do not make security claims stronger than the docs back up.
- Do not reply to criticism with benchmark numbers when the criticism is about trust, audit status, or correctness.
- Do not edit the post body materially after submission. Small typo fixes are fine; restructure looks insecure.
- Do not pivot to selling. No Patreon link, no "if you like this please star," no consulting offer at the end.