Crypto++

Repository on GitHub, which provides public git repositories with URLs.

Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.

Crypto++ does not use dead-end branches. It pollutes the Git log history. Instead testing forks are used and proposals are discussed.

Repository on GitHub, which uses git. git is distributed.

https://www.cryptopp.com/wiki/Release_Versioning

https://www.cryptopp.com/wiki/Release_Versioning

The README is the primary human readable document. https://github.com/weidai11/cryptopp/blob/master/Readme.txt. Each release has its own HTML page. For example, https://github.com/weidai11/website.

Each release has its own HTML page that highlights CVEs and major problems that were corrected. For example, from https://github.com/weidai11/website/blob/master/release565.html: "Crypto++ 5.6.5 was released on October 11, 2016. The 5.6.5 release was mostly a maintenance release. The release included two CVE fixes." Then, the CVE details are provided.

https://www.cryptopp.com/wiki/Bug_Report

https://github.com/weidai11/cryptopp/issues

Typically the projects response time is less than a day. https://github.com/weidai11/cryptopp/issues.

Typically the projects response time is less than a day. https://github.com/weidai11/cryptopp/issues.

GitHub allows searching of past and closed reports. https://github.com/weidai11/cryptopp/issues.

https://www.cryptopp.com/wiki/Bug_Report

We do not support private vulnerabilities. As soon as we get a private report we forward it to the mailing list at https://groups.google.com/forum/#!forum/cryptopp-users.

Typically the projects response time is less than a day.

Non-trivial build file in repository: https://github.com/weidai11/cryptopp/blob/master/GNUmakefile. The project also supplies Autotools https://github.com/noloader/cryptopp-autotools, CMake https://github.com/noloader/cryptopp-cmake and Visual Studio project files for those who wish to use them.

Non-trivial build file in repository: https://github.com/weidai11/cryptopp/blob/master/GNUmakefile. The project also supplies Autotools, CMake and Visual Studio project files for those who wish to use them.

The project only requires GNU Make. CD into the project directory and run 'make -j 4'. It really is as easy as that. The project also supplies Autotools, CMake and Visual Studio project files for those who wish to use them.

Linux and OS X builds using Travis CI: https://github.com/weidai11/cryptopp/blob/master/.travis.yml. FreeBSD builds using Cirrus CI: https://github.com/weidai11/cryptopp/blob/master/.cirrus.yml. Android and iOS builds using Travis CI: https://github.com/weidai11/cryptopp/blob/master/.travis.yml. Windows builds using AppVeyor: https://github.com/weidai11/cryptopp/blob/master/.appveyor.yml.

'make test' and 'make check' work for me. It follows the GNU Coding Standards.

Our test suite is comprised of about 13 source files and covers about 80% of the library.

Linux and OS X builds using Travis CI: https://github.com/weidai11/cryptopp/blob/master/.travis.yml. FreeBSD builds using Cirrus CI: https://github.com/weidai11/cryptopp/blob/master/.cirrus.yml. Android and iOS builds using Travis CI: https://github.com/weidai11/cryptopp/blob/master/.travis.yml. Windows builds using AppVeyor: https://github.com/weidai11/cryptopp/blob/master/.appveyor.yml.

Crypto++ is a library of cryptographic schemes. Our governance requires test coverage for new algorithms and protocols. At minimum, a new algorithm will include Known Answer Tests (KATs). Public Key algorithms will include Pairwise Consistency Tests.

Crypto++ is a library of cryptographic schemes. Our governance requires test coverage for new algorithms and protocols. At minimum, a new algorithm will include Known Answer Tests (KATs). Public Key algorithms will include Pairwise Consistency Tests.

Testing includes -Wall -Wextra with GCC and Clang. On Windows, testing include /W4. We also have a test script from hell that builds the project in 50-100 permutations (depending on the platform and features available). The tests from hell include 6 different builds to tease warnings. Also see https://github.com/weidai11/cryptopp/blob/master/TestScripts/cryptest.sh.

Our governance requires us to clear warnings under reasonable flags. To date our "reasonable flags" includes -Wall -Wextra. Otherwise, we get mailing list messages and bug reports for them.

Testing includes -Werror when using GCC and Clang.

The development team includes one Security Architect from US Financial and US DoD. The other maintainers have CVs that includes years of cryptography and security experience.

The library has also been FIPS 140-2 validated by the US government. The FIPS 140-2 validation includes a SP800-56a audit for processes and procedures.

The development team includes includes members of OWASP. The other maintainers have CVs that includes years of cryptography and security experience.

The library has also been FIPS 140-2 validated by the US government. The FIPS 140-2 validation includes a SP800-56a audit for processes and procedures.

The library includes well known algorithms, like AES; and lesser known algorithms, like RC6, MARS and Twofish.

The project is a cryptographic library.

The project is a cryptographic library.

When available, the project implements 256-bits of security and above. 256-bits of security exceeds the US government's recommendations on key sizes. Also see https://www.cryptopp.com/wiki/Security_Level.

The project is a cryptographic library. The project includes weak and wounded ciphers for historical reasons and research purposes.

However, to use a weak or wounded cipher, a user must build the library with -DCRYPTOPP_ENABLE_NAMESPACE_WEAK. The setting is off-by-default. Then, a user can use a weak or wounded cipher within the Weak:: namespace. I.e., Weak::MD2, Weak::MD5, etc.

When available, the project uses 128-bits of security by default. 128-bits of security is the US government's recommendation nowadays.

The project includes ephemeral key exchanges, like DHE and ECDHE.

The library itself does not store secrets, like private keys, shared secrets or passwords. Users may build applications that do so, but the library does not.

The library includes approved software generators like NIST DBRG from SP800-90. The library also includes hardware-based PRNGS, like Padlock, RDRAND, RDSEED and DARN. DARN is the RDRAND equivalent on PowerPC.

The project signs its release; see https://www.cryptopp.com/wiki/Release_Signing. The project also uses a trusted distribution channel for downloads using TLS and a Let's Encrypt certificate.

The project's signing algorithm for release tarballs is SHA-256.

The project typically responds to bugs within one day. Some patches take longer, but the patches are made available as soon as it is ready (i.e., passes testing).

The project typically responds to bugs within one day. Some patches take longer, but the patches are made available as soon as it is ready (i.e., passes testing).

The library does not publish private keys, shared secrets or passwords. Or not that we know of.

The project uses Coverity Scan on Linux and OS X. The project uses Visual Studio Enterprise Analysis on Windows. Finally, the project uses the Looks Good To Me continuous security analysis. Also see https://www.cryptopp.com/wiki/Coverity_Scan and https://lgtm.com.

The project uses Coverity Scan on Linux and OS X. The project uses Visual Studio Enterprise Analysis on Windows. Finally, the project uses the Looks Good To Me continuous security analysis. Also see https://www.cryptopp.com/wiki/Coverity_Scan and https://lgtm.com.

The project typically responds to analysis findings within a hour when run manually, or within a day when reported by a user.

The project uses Valgrind and Sanitizers to test for runtime violations. Valgrind detects memory and thread problems. Santiziers include Asan, Msan and UBsan.

The projects self tests also "fuzz" certain interfaces attempting to crash the test suite. The fuzzing occurs under Valgrind, Asan and Msan.

The project uses Valgrind and Sanitizers to test for runtime violations. Valgrind detects memory and thread problems. Santiziers include Asan, Msan and UBsan.

The projects self tests also "fuzz" certain interfaces attempting to crash the test suite. The fuzzing occurs under Valgrind, Asan and Msan.

The project typically responds to analysis findings within a hour when run manually, or within a day when reported by a user.