Re: [sqlite] R: R: Crypto lib for Sqlite - suggest required
Just to add my $0.02 We use http://www.safenet-inc.com/ HASP HL Encryption. (We use HASP keys for end user products so it was 'free' to my internal product tracking system db.) This key allows the exe to get encrypted and optionally a data file as well. The encryption of the program provides us with some security against a password being saved within the exe in clear form. When it comes to data encryption though, the performance penalty we suffer is 2x to 4x. Also, HASP HL data encryption + Sqlite + Windows 7, 64 bit editions don't work reliably. The HASP envelope does prevent an executable from running with a debugger open. It may be that newer versions of compiler or key will work, but I can't say that they will (nor does safenet's technical support actually provide answers). Bitter experience so far says Don't use HASP for data encryption. Adam On Sun, Jan 9, 2011 at 5:40 PM, Simon Slavin slav...@bigfraud.org wrote: On 9 Jan 2011, at 5:29pm, Roger Binns wrote: 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: As far as I can work out, the two solutions he pointed to encrypt at the field level. So if you understand the file structure of an SQLite database you can, for example, work out which records have the same values in either within a table or as across tables. It also gives you a handy-dandy plain/crypt pair since you will know that certain fields definitely start with 'CREATE TABLE ' and such things. On the other hand, these solutions are cheaper than the hwaci one. As with most encryption it depends how much effort you think the enemy will devote to attacking your technique. Simon. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users -- VerifEye Technologies Inc. 905-948-0015x245 151 Whitehall Dr, Unit 2 Markham ON, L3R 9T1 Canada ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] R: R: Crypto lib for Sqlite - suggest required
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/10/2011 06:41 AM, Adam DeVita wrote: The HASP envelope does prevent an executable from running with a debugger open. Only in simple cases. Since the executable and the key are in the hands (and total control) of the adversary, they can do anything. For example they can emulate/virtualize the process. It will stop someone with a copy of Visual Studio but will not stop someone determined and skilled. My preferred way of looking at this kind of thing is how much would an adversary charge to break things. This HASP thing changes it from a few hundred dollars to a few thousand. Roger -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0rNOQACgkQmOOfHg372QSb8QCgl68DWt2EBFon1z7GjUVtCfyR 1xYAoMi4Gd7I2yOu0Mx6J+x3z7L+dMMF =ENvt -END PGP SIGNATURE- ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] R: R: Crypto lib for Sqlite - suggest required
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
Re: [sqlite] R: R: Crypto lib for Sqlite - suggest required
-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
Re: [sqlite] R: R: Crypto lib for Sqlite - suggest required
On 9 Jan 2011, at 5:29pm, Roger Binns wrote: 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: As far as I can work out, the two solutions he pointed to encrypt at the field level. So if you understand the file structure of an SQLite database you can, for example, work out which records have the same values in either within a table or as across tables. It also gives you a handy-dandy plain/crypt pair since you will know that certain fields definitely start with 'CREATE TABLE ' and such things. On the other hand, these solutions are cheaper than the hwaci one. As with most encryption it depends how much effort you think the enemy will devote to attacking your technique. Simon. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
