-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/09/2011 02:20 AM, Marco Turco wrote: > My app is an accounting system. > This accounting system must support the exchange of db between users that > work with the this application > so I think the only way is to use the same key for all users.
Note that SQLite lets you attach additional databases so you don't necessarily need one single database with one password. For example if some of the data is sales and some is payroll and not every user needs to see both then you can put them in separate databases with different passwords attaching only what is needed. > This generate > a lack of security of course but anyway my executable is crypted itself > using an anti-debug cipher. And that still requires a key that is present on the same machine as the program. All you have done is made it take a little longer for a bad guy to see the plain code, but it isn't *that* hard since it is running on a machine totally under their control. - From what you have said so far I would strongly recommend that you just use the regular SQLite encryption extension from the SQLite team and ask the users for the database password(s) as you open/attach the databases. > I also need my app could read the same db crypted and also in the decrypted > format because for some special situations I need to provide my app running > with the Db decrypted. I think you misunderstand how the SQLite encryption extension works. The on disk storage format for SQLite is a series of fixed sized pages. The extension transparently encrypts each page on writing to disk and decrypts on reading. To use it you open/attach a database and then provide the password either via a C API or a pragma. You just make regular SQLite API calls and everything just works. http://www.hwaci.com/sw/sqlite/see.html The various other ones pointed out do something similar but since you go via their API layers they intersperse code to do encryption. I found it very hard to work out what they did for encryption since things like the algorithm used, IV (the usual weakness for home grown implementations) etc do matter. They also make other choices: http://sqlite.phxsoftware.com/forums/p/2536/9856.aspx > My doubt about the xor cryptation is that with this solution I can't manage > a text search into the db using a select but I need to read all data , > decrypt it and then make the text search, for this reason a low level > cryptation would be better in my case. You misunderstand how this works. Using a VFS merely changes how the data is stored on disk. The upper layers of SQLite do not know or care how data is stored on disk and they always see the data correctly and in the clear even if the VFS layer is doing encryption or obfuscation on reads and writes. - From everything you have said I'd strongly recommend you use multiple attached databases, prompt users for passwords (ie it is up to them to ensure security) and use the SQLite SEE extension from the SQLite authors since you know it works and gets the security right and will continue to do so. Roger -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0p8GEACgkQmOOfHg372QShCQCgr6BIWQMXJ9ZiJvLEYKe+Js43 oj4Ani/mX7/I4MXtQVRRXBe2WlQKNkZY =bifl -----END PGP SIGNATURE----- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
