rscrypto 0.3.1

Pure Rust cryptography: RSA, Ed25519, X25519, SHA-2/3, BLAKE3, AES-GCM, ChaCha20-Poly1305, Argon2, HMAC/HKDF, CRC. no_std, WASM, hardware acceleration.
Documentation
# rscrypto Task Roadmap

Internal working plan. This directory is intentionally gitignored.

Keep this file short. Detailed task lists live in focused docs:

- [`performance.md`]performance.md - measured performance gaps
- [`tls.md`]tls.md - rustls provider work
- [`fips.md`]fips.md - FIPS-readiness work
- [`rsa.md`]rsa.md - RSA compatibility path and non-goals
- [`pqe_pqc.md`]pqe_pqc.md - post-quantum work

## Rules

- Measure before optimizing.
- Keep the native API primary; adapters are compatibility layers.
- Keep `rscrypto` core independent from protocol stacks and FFI competitors.
- Prefer typed APIs over runtime mode flags.
- Do not add algorithms just to fill a table.
- Do not keep completed work in this roadmap.

## Priority Order

1. Close measured performance gaps that affect public claims.
2. Remove adoption friction for users migrating from established crates.
3. Build the minimum TLS provider surface outside the core crate.
4. Make the FIPS boundary documentable before considering formal validation.
5. Add public-key primitives required by real protocols.
6. Expand platform support only where CI or real hardware can verify it.
7. Add PQC only with official vectors, constant-time baselines, and a clear protocol destination.

## Active Work

### Performance

Source of truth: [`performance.md`](performance.md).

Current top losses:

- AES-GCM sustained throughput on POWER10 and RISC-V.
- SHA-256 streaming.
- PBKDF2-SHA256 low-iteration setup path.
- Ed25519 verification.
- HMAC-SHA384/SHA512 one-shot median parity.

Do not add speculative performance work here. If it is not backed by a current
benchmark row, it belongs in notes, not the roadmap.

### Adoption And API Compatibility

- [ ] Add explicit opt-in RustCrypto trait adapters:
  - [ ] `digest-trait`
  - [ ] `rustcrypto-aead`
  - [ ] `rustcrypto-signature`
- [ ] Finish migration guide examples that benefit from `rscrypto::{prelude::*, Type}`.
- [ ] Decide whether `HkdfSha512`, `Kmac128`, and `Cshake128` are real migration blockers or just symmetry requests.
- [ ] Keep BLAKE3 keyed output and verification docs clear: unkeyed hashes are arrays, keyed authenticators use typed tags.

### Symmetric Primitive Gaps

- [ ] AES-192-GCM only if a FIPS or protocol integration requires full AES key-size coverage.
- [ ] AES-CTR as internal glue for DRBGs, key wrap, or protocol support.
- [ ] AES-KW and AES-KWP with NIST vectors.
- [ ] AES-CCM only for concrete constrained-protocol demand.
- [ ] KMAC128 and cSHAKE128 only if compatibility pressure is real.

Rules:

- AEAD remains the preferred application encryption surface.
- Reduced-round variants stay out of scope.
- No generic CRC polynomial builder in core.

### Public-Key Work

Source of truth for RSA: [`rsa.md`](rsa.md).

TLS and WebPKI needs should drive this order:

- [ ] RSA public-key parsing.
- [ ] RSA-PSS verification.
- [ ] RSA-PKCS1v1.5 verification for legacy certificate chains.
- [ ] P-256 ECDSA verification.
- [ ] P-384 ECDSA verification.
- [ ] P-256 and P-384 ECDH.
- [ ] Ed25519 batch verification.
- [ ] Ed25519ph only if compatibility demand is clear.
- [ ] `X25519EphemeralSecret` only if protocol integration needs type-level one-use semantics.

Rules:

- No RSA private-key operations before blinding and side-channel strategy are explicit.
- No SHA-1 signing.
- SHA-1 verification, if ever allowed, must be behind a deliberate legacy-certificate boundary.
- No public generic big-integer API unless the crate truly needs one.

### TLS Provider

Source of truth: [`tls.md`](tls.md).

Target shape:

```text
application -> rustls -> rscrypto-rustls -> rscrypto
```

Core `rscrypto` must not depend on `rustls`.

### FIPS Readiness

Source of truth: [`fips.md`](fips.md).

The near-term target is structural readiness, not a certificate claim:

- [ ] boundary policy
- [ ] power-up known-answer tests
- [ ] conditional self-tests
- [ ] DRBG decision
- [ ] zeroization audit
- [ ] CAVP vector organization
- [ ] release provenance and SBOM

### PQC

Source of truth: [`pqe_pqc.md`](pqe_pqc.md).

Build order:

- [ ] ML-KEM
- [ ] classical + ML-KEM hybrid composition helpers
- [ ] ML-DSA
- [ ] SLH-DSA
- [ ] HQC only after standardization stabilizes
- [ ] protocol-layer HPKE/TLS helpers only after primitive correctness is boring

### Platform Work

- [ ] AArch64 SVE2 hash and GHASH candidates on real hardware.
- [ ] Windows ARM64 build and runtime-detection lane.
- [ ] Android aarch64 cross-build.
- [ ] iOS aarch64 cross-build.
- [ ] WASM `simd128` review for hashes/checksums.
- [ ] LoongArch64 only after Rust target features and CI reality are clear.

### Trust And Release Surface

- [ ] signed release artifacts
- [ ] CycloneDX or SPDX SBOM for tagged releases
- [ ] provenance attestations
- [ ] documented MSRV policy
- [ ] security advisory drill before v1
- [ ] side-channel testing plan where practical

## Closed Items Not To Re-Add

- `rscrypto::prelude` exists.
- Direct `std::io::Write` implementations exist for public digest and checksum states.
- `Aes128Gcm` and `Aes128GcmSiv` exist.
- The 2026-05-15 benchmark overview, README update, and perf chart update are complete.
- Expanded benchmark competitor rationale lives in [`../benchmarking.md`]../benchmarking.md.

## Explicit Non-Goals

- No TLS stack in the core crate.
- No FFI crypto dependency in core.
- No general SHA-1 primitive.
- No reduced-round ChaCha variants.
- No arbitrary CRC polynomial builder in core.
- No public generic big-integer API unless unavoidable.
- No PQC candidate sprawl.