[FR] Use BCrypt instead of OpenSSL on Windows

[lelegard]

Is your feature request related to a problem? Please describe.

For cryptographics features, libsrt is based on OpenSSL. On Windows systems, on Intel and Arm processors, OpenSSL creates multiple problems:

• A building and packaging issue (already discussed in PR Fix Windows installers #3113).
• A performance issue, significant with some chaining modes on Intel, dramatic with all modes on Arm (more details below).

Describe the solution you'd like

On Windows, using BCrypt (the Microsoft native cryptographic library for Windows) solves all these problems, building, packaging and performance.

Describe alternatives you've considered

Other cryptographic libraries exist but do not provide a better solution than BCrypt.

Additional context

The building and packaging issue has been discussed in details in PR #3113. In short, BCrypt is the only cryptographic library which is available by default on all Windows systems, all versions starting with Windows 10, all CPU architectures. An application using BCrypt can be built for all target architectures (x86, x64, Arm64), using any Windows build system on any architecture.

The rest of this issue focuses on the performance problems.

The evidences for the performance issues are based on my aesbench project. So far, this project focused on the comparison of AES performances with OpenSSL on various processors, on Linux or macOS.

To verify the impact of using OpenSSL on Windows, I just added tests for Windows and comparisons with BCrypt. Some results are astonishing.

In short:

• On Intel x64 systems, BCrypt is 50% faster than OpenSSL in GCM mode and 80% faster in XTS mode.
• On Arm64 systems, BCrypt is 40 times faster than OpenSSL in all modes (not 40%, 40 times, 4000%).

See tables of results on Intel Raptor Lake CPU and results on Arm Apple M3 CPU.

On Intel systems, I doubt that SRT uses XTS mode (more dedicated to disk encryption) but GCM mode is now the mode of choice for network transmissions, and the only remaining AES mode in TLS 1.3. It seems that Microsoft did a tremendous optimization job on the two mostly used modes in real life.

On Arm systems, the factor of 40 is obviously due to not using the specialized AES and SIMD instructions in OpenSSL on Windows. Arm and Intel processors have specialized instructions for cryptographic and vector processing. Serious cryptographic libraries use them and so does OpenSSL which contains many specialized assembly modules in their source tree. Given the performance results, OpenSSL obviously uses them on Linux and macOS but not on Windows. Since the complex assembly code exists in the OpenSSL source tree and considering the huge impact on performances, they must have run into some severe technical issue on Windows.

On a given Arm system, OpenSSL in a Linux virtual machine and BCrypt in a Windows virtual machine have similar performance profiles. We can safely say that the two use the specialized AES and SIMD instructions, with the same efficiency.

The 40 performance ratio between OpenSSL and BCrypt on Windows is exactly what I previously measured two years ago when comparing AES implementation using pure C code and assembly code with specialized instructions. So, even though this ratio seems huge, it is not surprising.

Therefore, I consider that using BCrypt instead of OpenSSL on Windows is important.

Thank you for all your work on SRT, past and future.

[lelegard]

If you need some sample code using BCrypt, I have created a demo here: https://github.com/lelegard/bcrypt-demo

The sample code illustrates the use of PBKDF2, AES-ECB, AES-CBC and AES-GCM. The code is validated using test vectors.

I haven't seen a builtin AES-CTR. So, if you need it, it must be implemented from AES-ECB and manual chaining.

I hope that this contribution will convince you to proceed 😃