In the past, I've used the pager to secure data. This involved encrypting the data before writing the data to disk and decrypting when loading from disk but also optionally hashing the page and storing the hash in extra data reserved for each page. If anyone tampered with the data, the hash would indicate this and an error could be thrown.
Also encrypting the page data makes it more difficult to tamper with the data. Products like sqlcipher do things like this (encryption, hashing), and it's fairly easy to see how it's done by pulling the sqlite source (not the amalgamation) and diffing it with the sqlcipher source. ~Mike > On Sep 7, 2017, at 6:34 PM, Jens Alfke <j...@mooseyard.com> wrote: > > > >> On Sep 7, 2017, at 2:47 PM, Keith Medcalf <kmedc...@dessus.com> wrote: >> >> Again, this is a detection for changed data and does nothing to prevent >> changes being made. > > The OP did not require that it be impossible to make changes (which is > clearly impossible without locking down write access to the file.) He > specifically said that detection of changed data was OK: > >>> For security reasons, a customer wants to be sure that a database line >>> cannot be modified after its initial insertion (or unmodified without being >>> visible, with proof that the line has been modified). > > The procedures I described provide detection that a row has been modified. > The first one doesn't make it evident that a row has been deleted, though the > second one does. > > —Jens > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
