-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/20/2011 02:32 AM, Robert Hairgrove wrote: > There are certain parts of an SQLite database or page header (the first > 100 bytes, for example) which have known values. I think it is perhaps > even dangerous to encrypt this data, at least with the same method used > for the rest of the file.
If the file is not a plain old SQLite file then you must encrypt *especially* the initial page. If you do not do this then regular SQLite can attempt to open the file and depending on luck can reject it, corrupt it or do other hideous things. > SEE encrypts the entire file, according to the information on the > website. All of the file contents are encrypted but the entire file is not encrypted at once. Instead each page is encrypted separately in order to allow for random access. (Note that getting this right is hard and requires careful design. For example did you note offset 20 in the SQLite header?) > So if I leave the headers unencrypted, am I disclosing anything I should > be (somehow) hiding? You are seriously wasting your time! If whole file encryption is ok then use 7zip and an unmodified SQLite copying across as needed. If you want the file encrypted while in use then use SEE. Any other scheme you come up with will have weaknesses you can drive a truck through. In addition there are likely to be bugs and your testing won't be thorough enough. Users hate it when you lose their data in the name of security that doesn't exist :-) > AES-256 is an accepted > standard, and AFAICT offers the best openly available encryption today. Algorithms are not that important - it is how they are initialized, combined, ordered, padded, randomized, compressed and many other things you haven't considered. If you really do still want to proceed then may I suggest just using plain XOR. It is trivial to test, hard to implement wrong and good enough. Anyone who would take the effort to "crack" it would find other ways anyway. It is also evidence - ie anyone who gets the plain text contents of the database had to make an effort to do so and cannot claim to have done so accidentally. This would then be sufficiently useful for discipline or prosecution. And if your customers care then they will already have existing solutions for encryption and protection which includes dealing with incapacitation of users, system administration, backups etc. It is not a good idea to defeat those. Alternatively provide this all SaaS style so that everything lives on systems you control with a web interface. That way the data and the encryption keys will not be living on an arbitrary end user system. Roger -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1g+tEACgkQmOOfHg372QQLiQCdHooHlbtW6J+ldqY3ZGROQ4hm xEEAmwYZ1at5ZroQsQBEUpVhXUNko+PH =wl8w -----END PGP SIGNATURE----- _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
