Rscrypto 0.4 adds constant-time release-gate pipeline

⚓ Rust    📅 2026-06-10    👤 surdeus    👁️ 3      

surdeus

Last week I posted rscrypto v0.3.1 across the normal channels to reach the community: Reddit, HN, etc. and got criticism/feedback that helped move rscrypto in a positive direction.

The strongest signal was that my constant-time wording was too compressed. A short README line about "constant-time MAC, AEAD, and signature comparisons" was not enough for a crypto crate. It mixed threat boundaries, evidence, and marketing language in a way that made readers ask the right questions.

rscrypto v0.4.0 is the follow-up: constant-time is now treated as scoped release evidence, not a general adjective.

Links:

What changed:

  • ct.toml is now the machine-readable source of truth for CT-critical surfaces, target policy, DudeCT cases, and BINSEC kernels.
  • just ct-full builds CT artifacts, validates the manifest, captures provenance plus LLVM IR/ASM/object disassembly, runs heuristic scans, runs required DudeCT cases, and runs BINSEC where the target/tooling supports it.
  • .github/workflows/ct.yaml packages hosted CT evidence per physical runner lane.
  • The docs now separate CT-claimed, CT-intended, best-effort, and unsupported configurations.
  • RSA private-operation evidence is tied into the CT gate and the existing dedicated RSA workflow.
  • RSA key generation now follows the crate's FIPS 186-5 Appendix A.1.3 probable-prime contract in code. This is not a CMVP/FIPS 140-3 validation claim.

Current CT release boundary:

  • Linux x86_64: artifacts, LLVM IR/ASM/object heuristics, DudeCT, and BINSEC on AMD Zen4, AMD Zen5, Intel Ice Lake, and Intel Sapphire Rapids lanes.
  • Linux aarch64: artifacts, heuristics, DudeCT, and BINSEC on AWS Graviton3 and Graviton4 lanes.
  • Linux riscv64gc, s390x, and powerpc64le: artifacts, heuristics, and DudeCT. BINSEC is not claimed for those ISAs today.
  • macOS aarch64: local artifacts, heuristics, and DudeCT through just ct-full. BINSEC is not claimed for Mach-O today.
  • WASM, no_std bare metal, Windows, Linux MUSL, macOS x86_64, GCC codegen, and Cranelift are not part of the current native CT release claim.

What is not a blanket CT claim:

  • DER/PHC parsing and other public syntax shape.
  • Algorithm/profile identifier mapping.
  • Key generation and OS randomness paths.
  • Public RSA verification/encryption work.
  • Raw hashes over public messages.
  • Checksums and non-cryptographic hashes.
  • Public length/shape rejection before a primitive boundary.
  • Argon2d, Argon2id, and scrypt as blanket local side-channel CT primitives. Their final comparisons and failure boundaries are still security-tested.

That list is a boundary, not an admission that secret-bearing primitive paths branch on secrets.

Performance is still public, but it is not the point of this post. The 2026-06-09 Linux CI fastest-external result is 3,958 wins and 5,878 wins-or-ties out of 6,525 matched comparisons, with a 1.60x geomean. Apple Silicon is 373 wins and 693 wins-or-ties out of 725, with a 1.41x geomean. The benchmark overview lists the losses beside the wins.

Limits:

  • Not third-party audited.
  • Not FIPS 140-3 validated.
  • Not a TLS stack, PKI toolkit, or key store.
  • Not a request to replace mature audited stacks blindly.

What I would value from this subreddit is narrow review:

  • Is the CT policy boundary clear?
  • Are the allowed/forbidden leakage categories right?
  • Is ct.toml shaped well enough to be reviewed over time?
  • Are the target exclusions honest and visible enough?
  • Are there CT-critical surfaces missing from the manifest?
  • Does any public wording still sound broader than the evidence?

If you find a concrete side-channel issue, correctness issue, or unsafe-code issue, please file it or use GitHub Private Vulnerability Reporting for sensitive findings.

For more details: rscrypto v0.4.0: Verifying Constant-Time Behavior Instead of Assuming It - DEV Community

1 post - 1 participant

Read full topic

🏷️ Rust_feed