dcrypt 3.0.0

Rust APIs for classical, post-quantum, and hybrid cryptographic primitives
Documentation
# dcrypt v2.0.0 withdrawal notice

Effective August 9, 2026, dcrypt `v2.0.0` is withdrawn. The supported
replacement is `v3.0.0`.

## Why v2.0.0 is withdrawn

`v2.0.0` contains important remediations for the four published stop-ship
advisories: safe-API memory unsoundness, Ed25519 universal forgery, GCM operation
nonce reuse, and unauthenticated streaming structure. Those fixes remain part
of the historical record.

The release nevertheless violates a defining dcrypt implementation policy. A
supported release must contain no unsafe Rust, native code, or FFI in any
published dcrypt crate or in its normal/build dependency closure. `v2.0.0` does
not meet that boundary, including through direct unsafe secret-storage code and
the dependency graph used for remediated cryptographic implementations.

This withdrawal is an implementation-policy and release-assurance correction.
Unsafe Rust or native dependencies do not automatically demonstrate a new
cryptographic exploit, and this notice does not claim that the four named
vulnerabilities persist in `v2.0.0`.

The subsequent v3 remediation review identified distinct advisories that do
affect `2.0.0`, including GHASH multiplication that compiled with
secret-dependent branches. Those later findings do not imply that any of the
four remediations named above regressed.

## User guidance

- Do not newly select `2.0.0`; its twelve crates are yanked from new crates.io
  resolution.
- Do not fall back to `1.2.3`; it contains critical and high-severity defects
  and its twelve crates are also yanked.
- Upgrade to `3.0.0` after reviewing its breaking migration and
  incident-response guidance.
- Existing lockfiles can continue to reference yanked versions. Treat a yank as
  release-selection guidance, not as remote deletion or retroactive protection.
- Earlier releases remain unsupported and have not been cleared.
- Review the published advisories and the incident-response guidance in
  [`SECURITY.md`]../../SECURITY.md. Updating alone cannot restore the security
  of affected ciphertext, keys, signatures, authorizations, or process memory.

The GitHub release object for `v2.0.0` was removed to prevent it from being
presented as a supported release. All 24 exact crate versions (`2.0.0` and
`1.2.3` for each of the twelve crate names) were verified as yanked on August 9,
2026. The annotated `v2.0.0` Git tag remains
immutable at commit `945e216c39ae3c8cb8c35d8401ceda32621887f8` as historical
provenance. Version `2.0.0` cannot and will not be overwritten or republished.

## Corrective-release contract

The supported `v3.0.0` release passed a blocking packaged-code and
dependency-closure gate requiring that:

- every published crate root contains `#![forbid(unsafe_code)]`;
- published dcrypt crates and their normal/build dependencies contain no unsafe
  Rust, native source, FFI declarations, native linking, or forbidden bridges;
- callers supply cryptographic randomness through a `CryptoRng` interface;
- XChaCha20-Poly1305 and FIPS 204 ML-DSA are standards-compatible, dcrypt-owned
  safe-Rust implementations;
- Ed25519 verification retains strict canonical, subgroup, and scalar checks
  with a fixed-step, mask-based secret-scalar path subject to target-specific
  compiler and timing checks; and
- external cryptographic implementations exist only as isolated test oracles
  outside the published dependency graph.

The release also passed the independent-oracle, interoperability, target,
timing-regression, Miri, fuzz, dependency-policy, and clean-package gates
documented in `CHANGELOG.md`. Those gates do not constitute an independent
security audit, formal verification, FIPS validation, or a blanket
compiler/target constant-time proof.