I’m an engineer at AWS working on AWS-LC, AWS’s open-source fork of Google’s BoringSSL. We have patch sets to CPython 3.10 through tip-of-main that build CPython’s
hashlib modules against AWS-LC’s
libcrypto respectively. We are committed to backwards compatibility and have CI jobs (here and here) asserting every change’s compatibility with many different open-source projects. We use these tests to catch compatibility regressions before they’re merged, and we plan to add a CPython compatibility test to this suite.
AWS-LC has recently made a number of CPU-specific performance optimizations for AWS Graviton 2, AWS Graviton 3, and Intel x86-64 with AVX-512 instructions. We’ve formally verified a subset of AWS-LC’s cryptographic primitives, and continue to invest in expanding this coverage. To support meeting FIPS 140-3 compliance requirements, AWS-LC can be built in FIPS mode. To give CPython users a well-documented and supported way to take advantage of these investments in performance, correctness, and compliance, we would like to upstream support for AWS-LC into mainline CPython. We believe that this would provide the best experience for users wishing to build CPython against AWS-LC. It would also allow users to skip the (often brittle) process of maintaining and applying their own patch sets to build CPython with AWS-LC.
The proposed integration would support all features of CPython’s
hashlib modules except for post-handshake authentication in TLSv1.3, as AWS-LC does not yet support this. In our fork of CPython we have a unit test asserting that CPython built against AWS-LC, lacking post-handshake authentication, behaves as expected. The only other feature gap we’ve identified is AWS-LC’s lack of support for the blake2s hash function, where we suggest using CPython’s own implementation of blake2. If you folks agree that this integration would be useful for upstream CPython, I’d be happy to put together a PR.