As others have pointed out, since SQLite must ultimately execute the query, it has to be unencrypted in memory at some point. In general, there is no way to protect data from prying eyes if that data must be used by a running program, because a competent adversary can inspect the program as it's running.
High-assurance applications such as those used for classified work incorporate countermeasures the make it practically harder to do this, but these offer absolutely no additional security from a theoretical standpoint. An example is the requirement to keep keys and keying material AES-wrapped in memory except at the point of use. As far as I'm aware, the state of the art in protecting secrets that must be kept in memory is so-called "whitebox encryption". You can google it, but essentially the idea is to take the state of a cryptographic primitive like AES and explode it out into a much more complex (and therefore harder to analyze), but equivalent representation. Here again, though, this just makes things a bit harder for an adversary -- it provides no additional security from a theoretical standpoint. Another approach to keeping secrets that you must use in running programs is to store them only in hardware security modules (HSMs). In this scenario, you have the HSM -- usually a USB or microSD device -- do whatever computation you need using its on-board CPU. The HSM then provides you the result of the computation (decrypted data or whatever). The HSM hardware guarantees that the secret itself is never revealed to the host computing device; getting the stored secret requires physically disassembling the HSM. HSM devices are commodity hardware now; you can buy one for under $50. It would be interesting to contemplate running all of SQLite on an HSM, as this would allow you to perform database transactions while ensuring the database itself was kept hidden from the host computing device. I'm not aware of any generically programmable HSMs capable of doing this, though, and of course your database would have to entirely fit within the HSM's on-board storage. These devices usually only have a small amount of storage -- enough to store 4096 keys, for example. But if there were an HSM that shipped with a "real" amount of memory and storage -- and was generically programmable -- there's no reason it couldn't be done. Dave Sent with inky<http://inky.com?kme=signature> <admin at shuling.net> wrote: Hi, In my C++ program, I will invoke SQLite to execute SQL queries. But these queries are just stored as normal string constants in C++ so it is easy to be decoded via reverse engineering method. Does SQLite provide a good way to encrypt the SQL query strings while does not affect the performance when executing the queries? Thanks _______________________________________________ sqlite-users mailing list sqlite-users at mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
