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

Reply via email to