Would you accept a provider based on native Win32 APIs?

On Windows, for various reasons it can be painful to build and bundle third-party cryptography libraries like OpenSSL, NSS, or LibTomCrypt.

As of Windows 7[^winver], it's completely possible to support SQLcipher's needs by using the functionality in the Windows CNG APIs (e.g. bcrypt.{lib,dll}), which is shipped and updated with the operating system.

That is, if a provider were written based on this, it would allow SQLcipher users on Windows to avoid having to build/link/distribute a third party cryptography library, since they'd just be using the "native" crypto API on the platform (similar to how macOS/iOS users can use CommonCrypto). I don't mind contributing this (and have started on it here, although it is still WIP), and maintaining it for you -- it would simplify my own open source code[^oss].

Unfortunately, I noticed that you've stopped accepting new providers. This makes sense, but I'm hoping you might make an exception for one based on native win32 APIs provided by the OS. So, is there any chance you'd accept it?

[^oss]: Concretely: I want this because it will simplify maintenance of rusqlite, which has a fair amount of complexity from building and statically linking a copy of OpenSSL on Windows, mostly to support a use case where users want SQLcipher and don't want to manage any C dependencies themselves. If SQLcipher had a provider that used native windows APIs, I could migrate these users to that.

[^winver]: These APIs were added in Windows Vista, but SQLcipher would need at least Windows 7 (e.g. for BCryptDeriveKeyPBKDF2).