Impact
internal/crypto/xcp reused the same random nonce for every 64KB block in a message. Any message over 64KB ends up with more than one block encrypted under the same key and nonce, which breaks confidentiality: C1 XOR C2 = P1 XOR P2. If an attacker knows or can guess the plaintext of one block, they can recover the plaintext of any other block in the same message. No key needed.
Reproduced this against the real encryption path in this repo, not a toy example. Both the symmetric and public-key encryption paths are affected since they both go through xcp.
The same reuse also repeats Poly1305's one-time key, so forging part of an affected message is plausible too, though no working forgery was built to confirm it.
Every released version until v1.32.2 is affected. It's been there since the first streaming-encryption commit.
Patches
Every block now gets its own nonce: a fixed 16 byte prefix for the whole message, plus a per-block counter and a flag for the last block. This also means a truncated or reordered ciphertext fails to decrypt instead of silently returning partial or wrong data.
Old ciphertexts still decrypt fine. New encryption never reuses a nonce across blocks again.
Patched in v1.32.3.
Workarounds
None beyond upgrading. If you can't upgrade right away, avoid encrypting anything over 64KB with an affected version, and treat any ciphertext over 64KB you've already produced as possibly exposed.
References
CWE-323
joyahamad074 Reporter
Impact
internal/crypto/xcpreused the same random nonce for every 64KB block in a message. Any message over 64KB ends up with more than one block encrypted under the same key and nonce, which breaks confidentiality: C1 XOR C2 = P1 XOR P2. If an attacker knows or can guess the plaintext of one block, they can recover the plaintext of any other block in the same message. No key needed.Reproduced this against the real encryption path in this repo, not a toy example. Both the symmetric and public-key encryption paths are affected since they both go through xcp.
The same reuse also repeats Poly1305's one-time key, so forging part of an affected message is plausible too, though no working forgery was built to confirm it.
Every released version until v1.32.2 is affected. It's been there since the first streaming-encryption commit.
Patches
Every block now gets its own nonce: a fixed 16 byte prefix for the whole message, plus a per-block counter and a flag for the last block. This also means a truncated or reordered ciphertext fails to decrypt instead of silently returning partial or wrong data.
Old ciphertexts still decrypt fine. New encryption never reuses a nonce across blocks again.
Patched in v1.32.3.
Workarounds
None beyond upgrading. If you can't upgrade right away, avoid encrypting anything over 64KB with an affected version, and treat any ciphertext over 64KB you've already produced as possibly exposed.
References
CWE-323