Would you accept a provider based on native Win32 APIs? #450
Description
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 71, 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 code2.
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?
Footnotes
-
These APIs were added in Windows Vista, but SQLcipher would need at least Windows 7 (e.g. for
BCryptDeriveKeyPBKDF2). ↩ -
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. ↩