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