Roman Rokytskyy wrote:

> After quick look on this, I think, that probably the most
> open approach would be to discuss extracting the physical
> I/O part from Firebird (the part that writes pages on the
> disk, reads them, handles temp sort files, etc.), create a
> clean interface for it and let people develop the encrypted
> storage, for example.

> Comments on the approach?

Something to that effect would probably be the most flexible
but I imagine it would be the most difficult for both sides.

I am not sure how much difficulty Firebird has ever had with
sort files being left behind, certainly it doesn't seem to
have been an issue on any of my installations. Of course they
are still being written un-encrypted - which means that the
plain-text is on the disk somewhere, but this is also true of
operating system paging and hibernation etc, and you have no
control over those processes. So this begs the question of
whether you need to worry about apply to temporary files. If
the user/deployer doesn't care about what the operating system
is doing with temporary data then why should they care about
Firebird?

That line of thought makes me think that encrypting just the
database file is all that is required or appropriate - and
satisfies the request. The reason for wanting to argue in
that direction is that the API can possibly be simpler if we
are dealing strictly with fixed page size file accesses. I
don't know enough about Firebird's use of temporary file to
guess how difficult they could be to encrypt/decrypt.


As far as I can tell you are going to need an area of
un-encrypted data in the database (presumably in the main
header page or similar) for the salt/nonce/initialisation-vector
(or whatever term you prefer). This would probably need to
be at least 128 bits ... although I'd suggest 256 or 512.

The database page read/write interface needs extending so that
any plug-in can adjust it's encryption according to the page
that is being written (I imagine that probably means by file
offset rather than by some internal page number), and as Jim
pointed out we need a key initialisation API too.

At a guess I'd say the APIs need to be such that the plug-in
creates it's own object to manage the key schedule/cache data
and the API would pass it to each of the encrypt/decrypt API
calls as needed.


If you're going to do this properly you should also be doing
something about encrypting backups - are they paged too? (Or
if not encrypting them then making some sort of warning to the
user when they try to backup an encrypted database.)

You need to make certain that EVERY database (even a backup
or a restored database) uses a unique salt/nonce even (esp.) if
it is using the same key. If the user takes file copies ...
well that's at their own risk, there's nothing we can do about
that (the same risk applies to encrypted volume files).

--
Geoff Worboys
Telesis Computing