Hi, thank you for your suggests. 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. This generate a lack of security of course but anyway my executable is crypted itself using an anti-debug cipher.
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. 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. Marco -----Messaggio originale----- Da: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] Per conto di Roger Binns Inviato: domenica 9 gennaio 2011 05:16 A: sqlite-users@sqlite.org Oggetto: Re: [sqlite] R: Crypto lib for Sqlite - suggest required -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/08/2011 04:36 AM, Marco Turco wrote: > Essentially I would avoid that my competitors can look inside the Db > structure and import data. On any machine where the database is used the key will have to exist in plain form no matter how convoluted the encryption going on. Your competitors will always be able to run it under a debugger. You don't say if the database content is the same for everyone or if it is different for each user. If it is the same for everyone then all it takes is one bad user and the DB contents will be publishable for all. If it is different per user then I don't see the problem. The only way to be "secure" is to provide the data one value at a time via a web service where you can audit each and every request and not provide everything at once. (And anyone receiving that data can still republish it.) In these situations it is usually enough just to obfuscate the database so it isn't immediately apparent that SQLite is in use. A simple way of doing that is to write your own VFS that calls the normal VFS but xors all data that is being read and written. This is exactly that scheme using Python and demonstrates how much code it is: http://apidoc.apsw.googlecode.com/hg/example.html#example-vfs If you still want to go down the encryption route then be aware that getting encryption right is very hard. More accurately it is trivial to use encryption, and even easier to use it wrongly. People usually get it wrong. Some random subjects: IV, salt, key strengthening The SQLite paid for encryption module is a bargain. It is a one time fee and you get it forever. It will always work with SQLite as the versions change. It does security right and is always thoroughly tested alongside SQLite development. Work out the value of that and the value of your time. Since you won't really be able to prevent copying the data, what you should look for is ways of proving that someone has done so. Obfuscating the database is a good first start since no one could "accidentally" look at the contents - they had to put in deliberate effort. Then throw in some mountweazels: http://en.wikipedia.org/wiki/Fictitious_entry#Motivations_for_creation http://en.wikipedia.org/wiki/Trap_street This would give you enough evidence to sue a competitor. Roger -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0pNnIACgkQmOOfHg372QT8jwCg0DRP/QhGxrOWo2fWDsYNPZj4 tgUAoM0ReVOOJ9exG8rb9iz4cFqZJOWq =w+gv -----END PGP SIGNATURE----- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
