Copyright (C) 2026 Doan Luu Duc Tai This program is free software: you can redistribute it and/or modify it under the terms of the GNU Affero General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Affero General Public License for more details. You should have received a copy of the GNU Affero General Public License along with this program. If not, see . CHAT CRYPTOGRAPHY SECURITY REVIEW Date: 2026-10-30. Historical review of the initial Rust backend. The current OpenSSL migration is recorded in CHAT-OPENSSL-MIGRATION.txt. At that checkpoint, private-message use and deployment were not ready. This historical review is not the current implementation status; see CHAT-APPLICATION.txt and CHAT-PRODUCTION.txt for the implemented application. FIXED REQUIREMENT Encryption must remain RFC 9980 ML-KEM-1024 + X448 using v6 keys. The compatibility probe pairs it with ML-DSA-87 + Ed448 signatures. No fallback encryption profile is implemented or approved. The findings below apply to checkpoint 436e217, before the backend change. TEST RESULTS Sequoia OpenPGP 2.4.2 with its Rust backend generated password-protected v6 secret keys, serialized and reimported them, signed UTF-8 content, encrypted to both participants, and decrypted successfully for both participants. Wrong passwords, unexpected signers, and modified ciphertext were rejected. The same probe passed in actual Chromium using Rust compiled to WASM. Functional tests are not a cryptographic audit, constant-time analysis, conformance certification, or demonstration that side channels are absent. The test uses no user-supplied key files and does not provide chat service. RUSTSEC-2026-0387: REACHABLE DEPENDENCY Sequoia 2.4.2's crypto-rust backend selects cx448 0.1.1 for both X448 and Ed448. cx448 depends on crypto-bigint 0.5.5. Source paths within these exact published crates: sequoia-openpgp/src/crypto/backend/rust/asymmetric.rs x448_generate_key, x448_derive_public, x448_shared_point ed448_generate_key, ed448_sign cx448/src/x448.rs PublicKey::from(&Secret), Secret::as_diffie_hellman cx448/src/curve/montgomery.rs Montgomery scalar multiplication and projective-to-affine conversion cx448/src/field.rs elliptic_curve::bigint and constant-modulus Montgomery representation cx448/src/field/element.rs field subtraction, multiplication, inversion cx448/src/field/scalar.rs scalar arithmetic using crypto-bigint integer operations The flagged crate is part of the required curve arithmetic. It cannot be dismissed as an unused RSA dependency. The advisory covers timing variation in arithmetic intended to be constant-time and identifies >=0.7.6 as fixed. cx448 0.1.1 requires the incompatible 0.5 series. Updating Cargo.lock alone cannot satisfy that requirement with 0.7.6. Source changes or another backend would require a separate review and tests; no local cryptographic patch has been invented to bypass this gate. This establishes a reachable affected dependency and prevents a claim of unreachability. It does not prove practical key extraction from this WASM binary on a particular browser/CPU. No such exploit has been demonstrated. The hybrid construction's independent component may preserve protection under some component failures; that is not grounds for ignoring the audit. Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0387.html RUSTSEC-2023-0071: RSA Sequoia's crypto-rust feature also includes rsa 0.9.10. The probe generates only the specified PQ identities and calls their corresponding primitives; it does not generate an RSA key or exercise RSA private-key operations. That observation applies only to this closed, generated-input probe. It is not proof that a future importer, certificate verifier, authentication endpoint, or decryption interface cannot be induced to use another algorithm. The future application needs an explicit supported-algorithm policy and hostile-input tests before any narrower exception could be assessed. Advisory: https://rustsec.org/advisories/RUSTSEC-2023-0071.html BACKEND CHECK In the installed Sequoia 2.4.2 source, the Nettle and Botan asymmetric backends report these required composite algorithms unsupported. The OpenSSL backend conditionally supports them, depending on the available OpenSSL version/features. Its browser/WASM build has not been demonstrated here. Native OpenSSL support alone would not satisfy client-side browser encryption. The Rust backend requires allow-experimental-crypto and allow-variable-time-crypto. These are explicit prototype build opt-ins, not security approvals or claims that the selected operations are safe. OTHER AUDIT GATES The new dependency graph also contains multiple crate versions. Its exact graph is pinned in Cargo.lock. Duplicate bans have not been relaxed, and no vulnerability advisory has been ignored. License permissions for Sequoia and its dependencies must remain correctly attributed in generated notices. The project check must audit the whole workspace. A root-package-only cargo-deny invocation misses a workspace member that is not a dependency of the root CLI. The branch changes that invocation to --workspace. NEXT GATE Retain the fixed algorithms. Resolve the curve-backend dependency through a reviewed upstream-compatible fix or demonstrate an acceptable alternative backend in the browser. Repeat the native and browser tests, review imported hostile inputs, and pass the full dependency audit before private-message use.