Add tamper detection to the database

[karagog]

One flaw of using an unencrypted sqlite database is that anyone can open it and change its contents without anyone knowing. The entries themselves are safely encrypted and protected with a MAC (Message Authentication Code) so any unauthorized changes to this data will invalidate the file. However, the id's, hierarchy and file links are in plaintext because at the time of implementation I determined this information is not meaningful to an attacker. Now that I've had more time to think about it, I'm afraid an attacker might do things like shuffle the entries around or unlink files from their entries and such. Again, there is no fear they will be able to derive your secrets, only cause you grief. Therefore this is not a high priority but should be addressed eventually.

There are a couple ideas I thought of to fix this:

• Use a fully encrypted sqlite database driver. I'm afraid for what impact this will have on performance, but it's definitely worth investigating. Probably the rest of the data access layer could stay the same, just the database driver would change to be encrypted, and it would have to use the same credentials used to decrypt the data within it. This last point makes me nervous because it may weaken the strength of encryption if the sqlite driver encryption is not as strong (they may find it easier to crack the sqlite credentials, and once they do they will know the key to decrypt all the secure data within).
• Add a checksum column to the Version table. The checksum would incorporate all the ID's, parent ID's, rows and file ID links from the Entry table as well as the file ID's and lengths from the File table, and the checksum itself would also need to be authenticated to prevent tampering. The checksum doesn't have to incorporate the file or entry data, because that data is already authenticated by the encryption layer so if it's tampered with it will invalidate the file as well.

At the time of writing I don't know which is the way to go, but one needs to take extra special care in implementing the checksum, because any bugs will invalidate the entire file (though would be easily recoverable by regenerating the checksum). Every update to the database would need to be scrutinized and the checksum updated within every relevant transaction.