On 31 Jul 2010, at 6:12pm, Nikolaus Rath wrote: > When tracing down bugs in an application that uses SQLite, I have > repeatedly faced the problem that I wanted to send (or get) a copy of > the sqlite database without disclosing potentially sensitive contents.
You might like to know that the writers of SQLite maintain a non-free encryption version of SQLite: http://www.hwaci.com/sw/sqlite/see.html > Therefore I was wondering what the opinions are about including a > crypt() function in SQLite itself. So write the function yourself and use it as an SQLite external function. If it proved to be rock-solid for some months you can start exploring options for having it included in distributed versions of SQLite. > Is that a sensible idea or nonsense? Any decent programmer with experience of encryption systems would be able to crack such encryption in an hour or so. The more encrypted data in the database, the easier it would be to crack. However, a function like the one you propose would be useful against the zero-effort attempts -- casual theft by someone who has the opportunity to access your hard disk for a few minutes. One thing to consider is where you're going to store the password you need for decryption. If it's stored in your compiled software then it's fairly easy for someone to identify it. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
