Jim, > If there's any interest, I have some ideas on how to handle unattended > startup of an encrypted database that we could kick around.
I would like to have such a discussion, since I have found the discussion of the whole "key holder" discussion a little obtuse and seemingly mixing remote client/connection security with database file encryption. In my own thinking (perhaps naïve) about how encryption would be added to a database, I had thought the following: 1- The database header page would be stored unencrypted (as it is today), allowing the basic db details to be visible to the engine. 2- A "cert name/alias" would be added to the header, which would point to the key/cert that would be stored in an appropriate/secure location on the server (which would be defined in engine config or database ini/config). 3- Further the same cert would be (by default) used when any backup that would be created (unless a "unencrypted" backup was requested), and therefore the cert would also be necessary to restore the database. Using the above approach, a database/backups would be portable and would be accessible as long as the server contains the appropriate cert. As for the issue of cert security, being a Windows guy, I had thought that the native cert functions would allow for certs to be securely loaded and stored in one of the cert stores, since in order to load/import a cert the private key would be required. Sean ------------------------------------------------------------------------------ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
