# Hacker News

HN is the wrong place for a victory lap and the right place for a falsifiable artifact. The audience rewards specificity, hates hype words, and notices defensive writing the way other audiences notice typos. The strongest angle here is **not** "I made a crypto crate" — that triggers "rolling your own crypto" reflexively. The angle is **"I benchmarked pure-Rust crypto across CPU architectures most Rust crates never test, and here's the data."**

The case-studies layer in [`case-studies.md`](case-studies.md) shows this empirically: BLAKE3, Lucebox, and RustCrypto's `crypto-bigint` all worked on HN because they paired one strong technical claim with a public reproduction path and named the limits before critics did. Posts that flopped (MiroFish-style ambition, vague performance claims without hardware tables) lacked one or the other.

---

## Title

Use one of these. They are ordered by my own confidence; pick whichever feels most honest at submission time.

**Primary** — leads with the unusual thing, the architecture spread, with one number adjacent:

```text
Show HN: rscrypto, pure-Rust crypto across Linux CI and Apple Silicon benches
```

**Alternate** — frames the user pain instead of the artifact:

```text
Show HN: Crypto should not be where Rust portability stops
```

**Avoid**: "Fastest pure-Rust crypto." "Drop-in RustCrypto replacement." "Canonical Rust crypto library." Anything with "finally," "blazing," "bulletproof," "military-grade." HN auto-flags the first three the way a smoke alarm flags toast.

### Title rules I'm following

- No exclamation marks. None.
- One number, one architectural fact, one project name. Not three claims.
- Under ~80 characters so the title doesn't truncate in the front-page list.
- Specific verbs ("benchmarked") not adjectives ("fast").

---

## Link Target

| Best | Link to | Why |
|---|---|---|
| **1st choice** | A technical launch post (DEV article or GitHub Discussion with charts, methodology, caveats) | HN audience clicks through, reads, returns to comment with substance. Single artifact carries the post. |
| 2nd choice | The README on GitHub | Strong if the README's first screen is the bench table + Quick Start (it is). |
| Avoid | crates.io | Too thin for HN. Crates.io page exists for `cargo` users, not for HN readers. |

If the DEV article is live by submission, link there. If it isn't, link the GitHub README directly.

---

## First Comment

HN expects the OP to drop a context comment in the first ~5 minutes. Write it before you submit so you're not typing under pressure. Keep it short — long first comments read as defensive.

```text
I built rscrypto because crypto kept being where my Rust services stopped being portable. Different stack on the server, different stack on WASM, different answer per RISC-V/POWER/IBM Z target, different audit surface every time.

v0.3.0 scope: SHA-2/3, BLAKE2/3, Ascon, XXH3, RapidHash, HMAC, KMAC, HKDF, PBKDF2, Argon2, scrypt with PHC strings, RSA, Ed25519, X25519, six AEADs, and the full CRC family. One crate. Leaf features when you need one primitive (sha2, rsa, aes-gcm, ed25519, anything) or `full` for the whole stack. Zero default deps. No C, no FFI, no OpenSSL.

The unusual part is the 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, IBM POWER10, 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.

The headline Linux result is 3,545 wins and 5,210 wins-or-ties out of 5,832 fastest-external Linux CI comparisons, with a 1.61x geomean against the fastest matched Rust baseline. The Apple Silicon MBP M1 macOS/aarch64 full run adds 235 wins and 450 wins-or-ties out of 463 fastest-external comparisons, with a 1.25x geomean. Strongest categories are checksums (5.03x Linux CI, 2.76x Apple Silicon), SHA-3 / SHAKE (2.15x / 1.86x Linux CI; 0.94x / 1.32x Apple Silicon), large-input BLAKE3 (2.31x Linux CI, 1.80x Apple Silicon), AEAD (1.57x Linux CI, 1.47x Apple Silicon), and RSA import plus verification (1.32x Linux CI, 1.45x Apple Silicon). It is not universally faster — PBKDF2-SHA256 setup, X25519 DH, RSA verification on Arm/RISC-V, small-message AEAD rows, Apple Silicon BLAKE3 64 KiB rows, HMAC-SHA256 bulk rows, empty-message ChaCha20-Poly1305 rows, and SHA3-256 streaming rows are still pressure points. Every tie and loss is in the overview alongside every win.

Trust model: the portable Rust path is the byte-for-byte authority. SIMD and ASM kernels are accelerators, differential-tested against the portable path on every CI run; mismatch fails the build. Constant-time MAC/AEAD/signature comparisons. Zeroize-on-drop for secrets. Continuous Miri and libFuzzer on the lanes that fuzz cleanly.

This is not FIPS validated, not a TLS stack, and not a request to replace mature crypto in production. It's v0.3.0 asking for hard public review — API mistakes, unsafe/SIMD soundness, benchmark methodology, migration blockers from RustCrypto / blake3 / crc-fast. I would much rather get the rough feedback now than have someone discover a mistake when it's already embedded somewhere.

Repo: https://github.com/loadingalias/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
```

### Why this comment is shaped this way

- **Opens with motivation, not project name.** The repo title is in the submission already; the comment uses the slot for the why.
- **Scope is in one paragraph, not a bullet list.** Bullet lists in HN comments read as marketing. Inline prose with commas reads as engineering.
- **The platform breadth + IBM/RISE acknowledgement is up high.** Anyone skimming the comment sees the architecturally interesting bit before they bounce.
- **Numbers are specific and bounded.** "3,545 / 5,832" is verifiable; "much faster" is not.
- **The hedge precedes the request.** Naming "not FIPS, not TLS, not a request to replace mature crypto" before asking for review is the move BLAKE3 used in 2020 and `crypto-bigint` used in 2024. It doesn't sound defensive; it sounds careful.
- **Two links, not eight.** Repo and benchmarks. Anyone who wants more can navigate from there.

---

## Pre-Prepared Replies

These are first-draft replies for the most common HN crypto critiques. Each has a reason it's shaped this way; the reason matters more than the exact wording.

### "Rolling your own crypto is dangerous."

```text
Agreed, and the project is not asking anyone to trust novelty. The 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, oracle-crate differential tests, libFuzzer harnesses for parsers and streaming, Miri on the portable backends, and backend equivalence enforced for every accelerated path.

I would rather get the hard review in public now than hide the work until it's already embedded somewhere. Specifically reading for: API shape mistakes, unsafe block soundness, and benchmark methodology criticism.
```

Why this reply works: it agrees first, names the actual mitigations specifically (no hand-waving), and explicitly invites criticism. It does **not** argue.

### "Why not contribute to RustCrypto?"

```text
Some pieces may make sense upstream eventually. The reason this exists as one crate is architectural: a single feature-selectable dependency, one dispatch model (compile-time → runtime → portable fallback), one error/security model, one platform matrix, and no mandatory external crate stack for `full`. That shape is hard to get by composing independent primitive crates.

RustCrypto's per-primitive crates are excellent and I use them as benchmark oracles in CI. This is not a fragmentation play; it's a different tradeoff for users who want the whole toolbox in one auditable dependency.
```

Why: acknowledges RustCrypto's quality directly, names the architectural reason without disparagement, and reframes the question from "why fork" to "different tradeoff."

### "The blake3 crate is already heavily optimized."

```text
Yes, and the claim here is narrow on purpose: large one-shot/keyed/derive-key inputs ≥64 KiB are 2.31x geomean faster on Linux CI and 1.80x on the Apple Silicon MBP M1 run. I do not claim universal BLAKE3 dominance — tiny inputs, 64 KiB Apple Silicon rows, and some environments are closer or lose. The benchmark overview keeps those caveats visible alongside every speedup.

If your workload is tiny inputs or you need the most established standalone BLAKE3 crate, keep `blake3`. The migration story is for people who want one crypto dependency for many primitives, with BLAKE3 being one of them.
```

Why: agrees, scopes the claim narrower than the critic's framing, and explicitly tells some users not to migrate. Naming who shouldn't migrate is one of the most trust-building moves you can make on HN.

### "Zero dependencies — really?"

```text
Zero *default* dependencies. The `full` primitive stack also avoids external crypto crates and C libs. Optional integration features can pull `getrandom` (entropy), `serde` (encode wrappers for non-secret types), or `rayon` (parallel BLAKE3 / Argon2). Each of those three is opt-in via a named feature flag and stays out of the dependency graph until you ask for it.

The exact graph is whatever `cargo tree --no-default-features --features full` prints — happy to drop the output here if useful.
```

Why: precise, names the three optional crates by purpose, and offers to produce the exact `cargo tree` rather than asking the reader to take it on faith.

### "Are the SIMD/ASM paths constant-time?"

```text
The MAC, AEAD, and signature comparison paths are constant-time by construction — `ct::constant_time_eq` with a `black_box` barrier, no early exit, no branch on secret bytes. RSA private operations also have a manual Linux Miri lane plus a first-order timing leakage gate on x64 and arm64; the release evidence lives in `docs/security/rsa-side-channel-audit.md`. The SIMD/ASM kernels themselves are constant-time on the data path (no data-dependent branches in the hot loops), but I have not had a third-party formal verification of every accelerated backend.

`portable-only` is a single feature flag that forces every dispatcher to the constant-time portable backend and bypasses runtime SIMD invocation, for deployment modes where the audited code path needs to be the only running code path (FIPS / DO-178C / ISO 26262 / IEC 62443).
```

Why: distinguishes what's enforced from what's not, names the specific tooling that hasn't been applied yet (transparent about the next-layer gap), and points at the deployment-mode escape hatch.

### "Are the benchmarks reproducible?"

```text
Yes. The CI workflow that produces them is in `.github/workflows/bench.yaml`. The raw Criterion output is checked into `benchmark_results/<date>/<os>/<arch>/results.txt`. The overview at `benchmark_results/OVERVIEW.md` recomputes from the raw medians; the script lives in `scripts/`.

Speedup is `external_crate_time / rscrypto_time`, computed from raw Criterion median times. Wins are `>1.05x`, ties `0.95x..1.05x`, losses `<0.95x`. Every tie and loss is in the overview.

If you want to reproduce on hardware I haven't tested, the runner setup and `just bench` invocation will give you the same numbers; happy to walk through it.
```

Why: names the exact files, defines the metric precisely, offers help for reproduction. This is the move Lucebox/Megakernel used to land a bold systems claim — methodology adjacent to the claim.

---

## Submission Timing

- **Day**: Tuesday, Wednesday, or Thursday. HN front-page rotation favors midweek; Monday is heavy with weekend-batched submissions, Friday afternoon and weekends have lower active reader counts.
- **Time**: roughly 8:00–10:00 US Eastern. Captures the US morning coffee window and EU early afternoon. Submissions later than 14:00 ET tend to compete with the day's already-established threads.
- **Pre-flight checklist** (before you press submit):
  - The submitted link must be live and load instantly (no broken images, no GitHub rate limits).
  - Your first comment is in your clipboard.
  - You have 60 minutes blocked off to reply to comments.

---

## Submission Mechanics

- **Submit from your account**, not a fresh one. New accounts are auto-throttled and Show HNs from sub-90-day accounts get less ranking weight.
- **Press submit, then immediately post the first comment.** The 5-minute window is when readers form their initial impression of OP.
- **Watch the page for 60 minutes**. Reply to every comment in the first hour, even one-line ones. HN's flag/upvote ratio is decisive in that window.
- **Do not edit the title after submission**. HN will not resurface the post in `/newest`, and edits look insecure.
- **Do not ask anyone to upvote.** HN actively bans accounts for vote rings and reads timing patterns to detect them.

---

## What Not to Do

- **Do not repost if the submission doesn't catch.** A repost from the same account inside 24 hours gets auto-collapsed; a repost from a different account looks worse.
- **Do not use "fastest", "best", "canonical", "finally", "blazing", "bulletproof", or any superlative without a number adjacent.** HN crypto readers downvote these reflexively.
- **Do not argue from authority.** Link tests, benchmarks, source files, and CI logs. "Trust me" is the worst possible argument for crypto.
- **Do not hide losses.** HN will find them; better that you point at them in the first comment.
- **Do not get into Twitter-style flame replies.** Hostile replies cost you more than rude critics do.
- **Do not include images in the submission.** HN strips them; you'll just look like you don't know HN.

## What To Do When It Does Catch

If the post lands on the front page:

- **Stay in the thread for the first 4 hours.** That's where the highest-quality questions arrive, and where engagement-then-silence loses you readers.
- **Track every concrete bug report or API critique** as a GitHub issue, linked back from your reply. "Filed as #N" is one of the most trust-building things an OP can write.
- **Don't pivot to selling.** No "we also offer," no "if you like this please star," no Patreon link. The HN audience reads those signals as expensive.
- **Write a 24-hour follow-up comment** at the end of the thread summarizing the issues filed, the reviews completed, and what's actionable for the next release.
