[sqlite] Q. about core SQLite library
Hello. My name is Ray Gold with Berliner, Corcoran & Rowe, LLP in Washington, DC. I am writing to ask if the core SQLite library (not the proprietary SQLite Extensions) has any encryption/decryption capabilities. Thanks very much for your help! Ray ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Q. about core SQLite library
On Tue, Jan 12, 2010 at 02:53:55PM -0500, Ray Gold scratched on the wall: > Hello. > > My name is Ray Gold with Berliner, Corcoran & Rowe, LLP in Washington, DC. > > I am writing to ask if the core SQLite library (not the proprietary > SQLite Extensions) has any encryption/decryption capabilities. No. However, the SQLite Encryption Extension is maintained by the same people that maintain the core library. It is "proprietary" only in the sense that it is commercial, licensed software. The core library does provide hooks to the OS layer and the file-system layer. It is possible to write your own encryption layer if the extension did not meet your needs. -j -- Jay A. Kreibich < J A Y @ K R E I B I.C H > "Our opponent is an alien starship packed with atomic bombs. We have a protractor." "I'll go home and see if I can scrounge up a ruler and a piece of string." --from Anathem by Neal Stephenson ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Q. about core SQLite library
Jay A. Kreibich wrote: > On Tue, Jan 12, 2010 at 02:53:55PM -0500, Ray Gold scratched on the wall: > >> Hello. >> >> My name is Ray Gold with Berliner, Corcoran & Rowe, LLP in Washington, DC. >> >> I am writing to ask if the core SQLite library (not the proprietary >> SQLite Extensions) has any encryption/decryption capabilities. >> > > No. > > However, the SQLite Encryption Extension is maintained by the same > people that maintain the core library. It is "proprietary" only in > the sense that it is commercial, licensed software. > > The core library does provide hooks to the OS layer and the > file-system layer. It is possible to write your own encryption > layer if the extension did not meet your needs. > >-j > > I would avoid using the OS layer. While you could implement your own encryption at the file system level, the license for the encryption extension is relatively inexpensive and maintained for you. As I understand it, once purchased, it is good indefinitely. Further, if it doesn't meet your encryption needs (unlikely) you could extend the encryption extension easier than adding encryption at the file system level. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Q. about core SQLite library
On Wed, Jan 13, 2010 at 11:07:50AM -0800, Mark Spiegel scratched on the wall: > > > Jay A. Kreibich wrote: > > On Tue, Jan 12, 2010 at 02:53:55PM -0500, Ray Gold scratched on the wall: > >> > >> My name is Ray Gold with Berliner, Corcoran & Rowe, LLP in Washington, DC. > >> > >> I am writing to ask if the core SQLite library (not the proprietary > >> SQLite Extensions) has any encryption/decryption capabilities. > > > > No. > > > > However, the SQLite Encryption Extension is maintained by the same > > people that maintain the core library. It is "proprietary" only in > > the sense that it is commercial, licensed software. > > > > The core library does provide hooks to the OS layer and the > > file-system layer. It is possible to write your own encryption > > layer if the extension did not meet your needs. > I would avoid using the OS layer. I was under the impression that is how SEE works. Hooking the SQLite Virtual File System interface seems like a very straight forward method. All you really need to do is splice your code between the VFS that the SQLite engine sees and the native VFS layer that comes with the distribution, adding a bit of extra code to xRead() and xWrite() to munge the data. I've never tried it but the documentation makes it look like something you could do without modification to the core source and with very little code other than the actual encrypt/decrypt routines, plus the interfaces required to configure them. No actual file system code, nor any OS specific code. In theory. 8-) http://sqlite.org/c3ref/vfs.html http://sqlite.org/c3ref/io_methods.html > the license for the encryption > extension is relatively inexpensive and maintained for you. As I > understand it, once purchased, it is good indefinitely. Further, if it > doesn't meet your encryption needs (unlikely) you could extend the > encryption extension easier than adding encryption at the file system level. Yes. I would definitely encourage people to look at the supported product before going off and writing their own. The value, cost, and license terms are exceptionally good. It is the right choice for most commercial situations. -j -- Jay A. Kreibich < J A Y @ K R E I B I.C H > "Our opponent is an alien starship packed with atomic bombs. We have a protractor." "I'll go home and see if I can scrounge up a ruler and a piece of string." --from Anathem by Neal Stephenson ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Q. about core SQLite library
> I was under the impression that is how SEE works. Hooking the SQLite > Virtual File System interface seems like a very straight forward method. > All you really need to do is splice your code between the VFS that > the SQLite engine sees and the native VFS layer that comes with the > distribution, adding a bit of extra code to xRead() and xWrite() to > munge the data. I've never tried it but the documentation makes it > look like something you could do without modification to the core > source and with very little code other than the actual encrypt/decrypt > routines, plus the interfaces required to configure them. No actual > file system code, nor any OS specific code. > > In theory. 8-) > > http://sqlite.org/c3ref/vfs.html > http://sqlite.org/c3ref/io_methods.html > > > No, it is probably more correct to say that the SEE plugs into the pager. It does not layer the VFS. Look where the CODEC1 and CODEC2 macros are used. Mr. Kreibich should contact DRH and ask about the encryption extension. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Q. about core SQLite library
Sorry, Mr. Gold should contact DRH and ask about the encryption extension. My error. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Q. about core SQLite library
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jay A. Kreibich wrote: > All you really need to do is splice your code between the VFS that > the SQLite engine sees and the native VFS layer that comes with the > distribution, adding a bit of extra code to xRead() and xWrite() to > munge the data. It is certainly possible to do it this way. It is however a really bad idea to write your own encryption scheme. Anyone can come up with a design for the capabilities they cannot break themselves, but that does not mean that others cannot break it. (Note that I am not talking about the encryption algorithms themselves - I assume no one would be silly enough to try and come up with new ones of those - but rather how one or more encryption algorithms are combined to act on the data.) History is littered with experts (no less) who designed schemes that later turned out to be no good. Some examples are SSL version 1, SSL version 2 and WEP. There really are a lot of things to consider. For example if the scheme doesn't account for timing attacks (ensuring all routines take a constant amount of time no matter if or how much of the key is correct or incorrect) then it becomes rather easy to crack the correct key. Consequently it would be foolish to not use the SEE extension, and pay the small fee for it. You can then work on an improved scheme but need to ensure it is reviewed by multiple security experts and verify the implementation is solid, and at the very least better than SEE. This of course will set you back way more than SEE costs. Roger -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAktOYDcACgkQmOOfHg372QQ65wCfaeeQj27LcpksjAwhNOkh2Q/U 8BYAoLkDupRYnA/Q16cZPNHseTYT1kxm =iZWS -END PGP SIGNATURE- ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Q. about core SQLite library
On 14 Jan 2010, at 12:07am, Roger Binns wrote: > It is however a really bad idea > to write your own encryption scheme. [snip] > > History is littered with experts (no less) who designed schemes that later > turned out to be no good. Some examples are SSL version 1, SSL version 2 > and WEP. Yeah. Don't spend time writing encryption code unless you have studied encryption. It's one of those subjects which gets more complicated the longer you study it. And spotting 19 of the 20 trivial ways to crack your encryption still gets you a mark of 0%. Simon. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Q. about core SQLite library
On Wed, Jan 13, 2010 at 04:07:19PM -0800, Roger Binns scratched on the wall: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Jay A. Kreibich wrote: > > All you really need to do is splice your code between the VFS that > > the SQLite engine sees and the native VFS layer that comes with the > > distribution, adding a bit of extra code to xRead() and xWrite() to > > munge the data. > > It is certainly possible to do it this way. It is however a really bad idea > to write your own encryption scheme. Absolutely. I never meant to imply someone should write the actual encryption algorithm, only the glue to attach SQLite's pager to an existing crypto library. Anything else would be utterly foolish. Even then, mistakes with key management and proper defensive coding can frequently allow back-door attacks. For example, since the most obvious choice is a stream cypher that works on a per database-page basis, it would be advisable to use larger pages to avoid constantly re-starting the stream. One might also consider transforming the key based off page position so that you don't have any page headers or structure that could be analyzed as semi-known plain-text. You would also want to alter the new-page allocator to scramble any unused part of the page for the same reasons. > Consequently it would be foolish to not use the SEE extension, and pay the > small fee for it. As I said before, I think SEE is a great choice. It is a fantastic value and a logical first choice for anyone looking to evaluate encrypted databases. That said, it doesn't fit every need. Most notably, it isn't practical to use within an open-source project, commercial or otherwise. SEE may be very reasonably priced and come with a full source license, but it also comes with an NDA and a specific limitation on redistribution of the source code. Plus, if everyone would remember, the original poster specifically asked about alternatives to the SEE extension. I think dismissing SEE is a mistake, but that's their business, not mine. I'd like to assume they know what they're doing and have their reasons for looking elsewhere. I seriously doubt anyone could replicate the functionality of the SEE extension for less than the cost of a license. In fact, I suspect this is the main reason why there isn't a popular open-source alternative-- the real deal is a fantastic value. But there are still situations were SEE is simply not a feasible choice. I would also guess most of those situations are going to involve reasons and decisions that are firmly based in the realm of business, license, and political issues, and not technical issues. I have full confidence in the technical capabilities of SEE. But the world does not run on technical decisions alone. -j -- Jay A. Kreibich < J A Y @ K R E I B I.C H > "Our opponent is an alien starship packed with atomic bombs. We have a protractor." "I'll go home and see if I can scrounge up a ruler and a piece of string." --from Anathem by Neal Stephenson ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Q. about core SQLite library
> > All you really need to do is splice your code between the VFS that > the SQLite engine sees and the native VFS layer that comes with the > distribution, adding a bit of extra code to xRead() and xWrite() to > munge the data. > I implemented this approach once, it worked, VFS also so flexible you can even offset your data, for example write something unique seeding at the start of the file and shift the actual sqlite data to some offset. Although in this case xTruncate should be also adjusted. The only probable disadvantage of using VFS is that sqlite temp file (etilq ... on windows) are bypassed by the VFS as long as I noticed, so if in any case it is left in the system, the contents of temporary tables will be exposed. Although I also noticed some tricky method they (temp files) are created with, so even if I terminate the process unexpectedly they still dissappear afterwards. Max ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
