ON Thursday, 7 September, 2017 10:32, Jens Alfke <j...@mooseyard.com> wrote:

>> On Sep 7, 2017, at 1:38 AM, Paxdo <pa...@mac.com> wrote:

>> But of course, someone who knows this checksum and its salt could
>make changes on the table and recalculate all checksums. :-(
>Use digital signatures. I can think of two approaches:
>(a) Sign each row. The program doing the insertion would need to know
>the private key, while validation would require only the public key.
>The drawback is that whoever does the insertion can later modify any
>row, although no one else can.

This is somewhat misleading.  Anyone can update the row.  Only someone in 
possession of the private key can generate a correct signature, however.  This 
does not prevent updating the row (or deleting it).  It only permits detection 
of updates made without the private key and without re-generating a valid 

It is somewhat better than a simple hash in that generating a validation token 
requires possession of the private key, but it does nothing to prevent changes.

>(a) Use external signatures as official validation. Periodically have
>the entity with the private key compute a digest of the entire data
>set and sign that, adding the signature to the database. Anyone can
>regenerate that digest and verify the signature. The drawback is that
>any recent additions since the last signing aren't safe. And again,
>the entity with the private key can modify anything.

Again, anyone can modify anything.  Only the possessor of the private key can 
generate a valid signature however.  Again, this is a detection for changed 
data and does nothing to prevent changes being made.

>To guard against modifications by the private-key owner, other
>parties can remember previous signatures and raise a ruckus if they
>ever change in the future.
>sqlite-users mailing list

sqlite-users mailing list

Reply via email to