-
Notifications
You must be signed in to change notification settings - Fork 604
CVE 2026 16001
Issue affecting: BC C# .NET 2.6.2 and earlier, and the 2.7.0-beta.98 pre-release.
Fixed versions: BC C# .NET 2.7.0
Platform affected: All CLRs.
An IesEngine constructed without a block cipher works in stream mode: the message is XORed with output from the key derivation function (KDF), and the MAC key was taken from the KDF output immediately after that keystream, so its position depended on the length of the message. In BC C# .NET, IesEngine is always initialised with static keys on both sides, and the KDF input is just the agreed secret and the fixed derivation parameter, so every message between the same pair of keys draws on the same KDF output.
An attacker who has seen one encrypted message and knows its plaintext can recover the keystream for that message, and that keystream contains the MAC key of every message shorter than it by at least the length of the MAC key. With it the attacker can produce shorter messages, with content of their choosing, that the recipient decrypts and accepts as authentic, without knowing either private key. Only applications that use IesEngine directly in stream mode, with either DH or EC Diffie-Hellman, are affected. Block-cipher mode (the constructor taking a BufferedBlockCipher, used with IesWithCipherParameters) takes the MAC key from a fixed position and is not affected, and the "IES" and "ECIES" ciphers returned by CipherUtilities cannot be initialised in any version.
BC C# .NET 2.7.0 takes the MAC key from the start of the KDF output and the keystream from the bytes that follow, so the MAC key is never part of the keystream, whatever the message length. This changes the stream-mode output: messages encrypted in stream mode by earlier versions cannot be decrypted by 2.7.0, and the reverse. Block-cipher mode output is unchanged. The fix does not change the fact that stream mode with static keys uses the same keystream for every message, so a known plaintext still reveals other messages of up to the same length; this mode should not be used for data that must stay confidential.
Earlier versions have no setting that changes this, so upgrading is recommended. Where that is not immediately possible, applications should move from stream mode to block-cipher mode. Before 2.7.0, block-cipher mode removes padding before it checks the MAC, so an application using a padded mode such as CBC should report every decryption failure in the same way, without revealing whether the padding or the MAC check failed; 2.7.0 checks the MAC first.
The corresponding issue in BC Java was fixed in BC Java 1.85 (CVE-2026-12816).
Fix Commits:
Credit: Discovered by Claude, Anthropic's AI assistant, and triaged by the Anthropic security team in collaboration with Anthropic Research.