[cryptopp-modern] Add new port

[Coralesoft]

Summary

• Adds new port cryptopp-modern version 2026.2.0, a maintained fork of Crypto++ with improved CMake support and a reorganised code layout.

Security

• This release includes a fix for CVE-2024-28285, a fault-injection issue in ElGamal, DLIES, and ECIES hybrid decryption. Under the reported fault model, repeated faulted decryptions can enable differential fault analysis and private key recovery.

• Upstream status (as of February 2026): the public tracking issue remains open:
  Leak the Secret Key of Elgamal Encryption in Cryptopp via Rowhammer weidai11/cryptopp#1262

• Advisory and technical write-up:
  GHSA-fmg6-fhgx-qmgq
  https://github.com/cryptopp-modern/cryptopp-modern/blob/main/docs/security/CVE-2024-28285.md

Build notes

• Static library only.
• Disables assembly optimisations on Windows x86 and ARM to avoid build failures.

Test results

• Tested successfully on Windows x64 with Visual Studio 2022.

Checklist

• Port builds successfully.
• No trailing whitespace or formatting issues.
• Licence file is properly installed.
• CMake config and pkg-config files are properly installed.

[Coralesoft]

@microsoft-github-policy-service agree

[dg0yt]

AFAIU this is a fork of cryptopp, but only one lib providing the same lib and symbols can be accepted in this registry. Accepting the new port might mean delisting the other port.

[Coralesoft]

Thanks for raising this.

You’re right: cryptopp-modern is a fork of Crypto++ 8.9.0 and deliberately provides the same ABI and symbols. The idea is to offer a maintained, drop-in compatible variant for people already using Crypto++, with fixes (including the Marvin / CVE-2023-50979 mitigation), a modern CMake setup, CI, and additional algorithms like Argon2 and BLAKE3.

My intention with this PR isn’t to force a particular policy outcome, but simply to make that maintained, drop-in option available to vcpkg users. If, given the “one library / one set of symbols” rule, the right approach is to use cryptopp-modern behind the existing cryptopp port, or to keep the current port as-is and close this PR, I’m happy to follow whatever best fits the registry.

[BillyONeal]

It looks like the other package managers are just trying to patch the known CVEs e.g. https://metadata.ftp-master.debian.org/changelogs//main/libc/libcrypto++/libcrypto++_8.9.0-2_changelog

[Coralesoft]

That's great news, i have a PR for this CVE with the repo weidai11/cryptopp#1335 since October

[BillyONeal]

/cc @noloader

[BillyONeal]

Unfortunately as this would effectively change the maintainer of cryptopp for vcpkg we are very hesitant to make that change without seeing that upstream is well and truly dead. I asked Microsoft crypto board about CVE-2023-50979 and paraphrased they said "we ban PKCS#1 v1.5 padding anyway".

There are other package management systems like apt for which adding this fork would not create mutual incompatibilities; you may wish to speak with the Debian maintainers.

[BillyONeal]

I'm going to draft rather than close this because there is nothing wrong with the code here and if we start seeing this fork replace the original more broadly we may merge it.

[Coralesoft]

FYI, I clicked ready for review when I pushed the update and I can’t change it back from my side. Happy for it to be treated as draft. I’ll keep it maintained and update this thread if adoption shifts.

[dg0yt]

clicked ready for review when I pushed the update and I can’t change it back from my side.

For reference, top right in my screen (for a PR which I authored):

[BillyONeal]

I took another pass over other package management systems to see if they had adopted something else or merged more extensive patches and unfortunately I don't see that, so set back to draft for now. (It seems you didn't intend to unset draft but that caused me to double check anyway)