Removing primary key values and timestamps does minimal things. Anyone with the tools, knowledge, will and if possible, backed by a legal warrant, can use legal resources to dig up 'removed' data.
You need to consider that there are temp files, file slacks, memory slacks... especially in the NTFS filesystem which may contain residues of unencrypted database files that have been supposedly 'deleted'. It is still best to encrypt the file from the very start of it's creation so that the fragments of it, even if retrieved and recovered, would still have to bypass the AES 128 encryption H2 uses for encrypted storage if you use it's option right from the start. Removing values selectively or randomly from a file can be recovered via computer forensics mean and thus insecure. Leaving the database unencrypted in the beginning and later on encrypt it, I am afraid some fragments may have been somewhere in the disk where it can be recovered. If you are not allowed to encrypt the database, and you try to encrypt just the blobs, the other data in the main database (non-lobs) would simply betray the contents of the blob and also, simply selectively encrypting only blobs or selective manipulation parts of H2 data is not in H2 features unless you want to make your own libraries to compliment it. > The database is disk-based.. > Yes, encrypting the database would work but unfortunately that is not > an option for reasons i cannot disclose. > > Simply wiping all traces of the primary key values and timestamp > columns for each row would be enough i suppose... > > I might encrypt the blobs to work around that problem maybe. -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To post to this group, send email to h2-database@googlegroups.com. To unsubscribe from this group, send email to h2-database+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/h2-database?hl=en.
