Repository navigation
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. ↩
Activity
sjlombardo commentedon Dec 20, 2022
Hello @thomcc - I apologize for the delayed response and thank you for reaching out about this before submitting, we definitely appreciate you checking in first.
New providers tend to involve a lot of review, extensive testing, complicate licensing, fragment the user base, and increase our support load. For this reason, we are extremely reluctant to accept new providers unless there is a very compelling need. Accordingly, we've rejected four new providers within the last two years, and actively regret adding others before we established our more restrictive policy.
That said, the idea of a native crypto option does sound appealing. I don't want to leave you hanging, but we're on the fence about it. We need to further consider this in the context of our open source and commercial edition road maps.
I can leave this ticket open for now, but would you mind if we circled back with you in the new year with a more definitive answer?
thomcc commentedon Dec 20, 2022
Yep, that sounds great to me. I agree that it's a lot of work, definitely I wouldn't suggest this if it weren't significantly more convenient for linking on windows.
(Note that this, unlike the others perhaps, should not complicate licensing at all, since it's using native system components)
nmoore-genetec commentedon Mar 13, 2025
Is there any update on this ? I also would like the flexibility of deploying on Windows without the need for openssl
alexeydott commentedon Jul 13, 2026
You might find it helpful to take a look at this fork; in it, the
sqlcipher_providerinterface is implemented using CNG primitives.It’s not exactly “standard” SQLite (I added a few extensions I needed and ensured C89 compatibility in some places so that sqlcipher could be compiled for use with Delphi/CBuilder), but as far as bcrypt is concerned, everything works exactly as intended—at least for my needs.