This page is intended to state the actions that are planned for future releases of Crypto++. Furthermore planned breaks of backwards compatibility are documented as long as possible before they take place here.
None of these actions are binding and items may be moved and removed, usually this will be discussed on the mailing list.
The following are the changes intended for Crypto++ 5.7 or 6.0 line.
Finish remediating UBsan, Asan, Valgrind and Enterprisa Analysis findings
Remove 5.6.3's CRYPTOPP_MAINTAIN_BACKWARDS_COMPATIBILITY_562
Remove existing stuff from CRYPTOPP_MAINTAIN_BACKWARDS_COMPATIBILITY, and new stuff to CRYPTOPP_MAINTAIN_BACKWARDS_COMPATIBILITY
Adding BLAKE2(Commit 30c1af2858da32e8 (Linux) and Commit d656f4404ac98d0c (Windows))
Re-work of ECIES interface
Adding Krawczyk's HMQV and Sarr's (et al) FHMQV
- Adding Edwards curve support, Bernstein's ed25519
Adding Poly1305(Commit 62e99837e8277290)
- May be a 6.0 feature, depending on features
May include a change to Integer class due to little-endianess order
Support for NIST DRBGs (HASH and HMAC)(Commit 5c932fcc3b6333e4 and Commit 2868452193e32156)
The following are the changes intended for Crypto++ 6.0 line. They will occur over time, and all of them will not show u in 6.0 proper.
Change DefaultBlockCipher and DefaultHash from 2-key TripleDes and SHA1
- Changing some public symbols
- Adding KeyDerivationParameters and reworking KDFs
- Adding a full set of KDF interfaces (KDF, KBKDF, PBKDF)
- Reworking RNG main class to support the NIST DRBGs and Fortuna
- Introducing TweakableBlockTransformation in preparation for Threefish
- Allow for OpenMP multithreading in function calls
Any feature in the following list is planned to be implemented at some point in a version to be determined. If it's not (yet) assigned to some release version this means no one currently plans to do it for this version. This doesn't mean it's impossible for the code to make it into the release. If a (secure) implementation is provided the maintainers will happily accept it and likely accept it for the next release currently in assembling stage.
Coverity scanning service
- Move weak/wounded algorithms into Weak:: namespace
- Support for scrypt, bcrypt, Argon2, Lyra2, Makwa, Catena (all PBKDF)
- Support for XTS and OCB modes of operation
- Support for PQ-Cryptography, for example McBits
- Support for EdDSA and Ed25519, Ed448, Curve25519, Curve448 (using the current ECC implementation and some wrappers)
Support for Poly1305
- Native Support for EdDSA...
Support for Blake2-b/s/bp/sp
- Support for Threefish and Skein (including KDF, MAC and stream cipher variants)
- Support for Fortuna
- Support for some Crypto Competition algorithms (authenticated encryption with public and private AAD values)
- Support forCryptoPP::FIPS140 namespace
- Support for CryptoPP::Engine class or namespace to provide access to a non-Crypto++ implementations, like iPhone hardware accelerated encryption via CommonCrypto or Windows CNG algorithms
The following provides a historical record of past goals and objectives.
- Fixed CVE-2016-7420
- Fixed CVE-2016-7544
- Shipped library in recommended state
The "shipped library in recommended state" caused a lot of problems for distributions, like Debian and Fedora. Too many symbols changed due to a couple of #define changes. The next release will be used to correct it with a non-trivial version bump.
- Fixed CVE-2016-3995
- Added Keccak
- Added ChaCha
- Added HMQV and FHMQV
- Added BLAKE2b and BLAKE2s
- Added CRC32-C
- Added Tweaked Roots for RW signatures
- Added NEON, ARMv7, and ARMv8 support
- Improved C++11 support
- Improved Windows 8 and 10 support
- Visual Studio 2010 default
Crypto++ 5.6.3 will likely be the last in the 5.6 line. For posterity, "currently" is July/August 2015.
The Crypto++ 5.6.3 release will include:
- CVE-2015-2141 remediation
- Sanitizer, Valgrind and Coverity findings remediations
- Warning cleanup under contemporary compilers
- Improved OS X support
- Additional platform support
- Improved automated testing support
- Basic C++11 support
Some things won't be fixed because of versioning requirements:
- GCC 4.8's finding warning: deleting object of polymorphic class... which has non-virtual destructor....
- Unaligned data access placed into an off-by-default state.
The unremdiated issues will be fixed in later versions of the library. In fact, some of them are already checked-in at GitHub.