1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
|
Copyright (C) 2026 Doan Luu Duc Tai <doan@luuduct.ai>
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 <https://www.gnu.org/licenses/>.
CHAT CRYPTOGRAPHY SECURITY REVIEW
Date: 2026-10-30. Status: blocked for deployment and private-message use.
Branch: feature/private-chat. Production and main remain unchanged.
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.
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.
|
