> No, you were told that it was built in encryption was investigated but
> abandoned (for the moment) because of the problems of key management
> and because of the existence of third party tools to solve the problem.

I would just like to chime in with a statement that to the best of my
knowledge there are no third party tools which solve the problem. There are
tools (e.g. TrueCrypt) which solve some of the issues, but overall they are
not very good for the purpose: Even if they didn't share the exact same
problem of key management Firebird has (my application still needs to supply
the key to the encryption utility), there's the big problem that they open
the database for all applications, while encryption embeded in Firebird
would only allow itself _if_called_from_that_single_user_application_ to
access the data. (In other words, if I store my database in TrueCrypt
volume, all that an attacker has to do is to run my application and then
copy the GDB file from the mounted volume; that would not be possible with
native encryption). OS's user rights do not solve this issue either - an
attacker will have administrative access, and even if he won't, all he needs
to do is to run GBAK while my application is running to get decrypted data.

> Even though YOU may not be trying to secure nuclear weapon access
> codes, and for YOU, a simple XOR based obscurity is sufficient, if
> Firebird claimed to offer built in encryption, you must understand why
> it could not be so easily breakable if offered by a DBMS.

As I understand it, the main issue here is providing Firebird with
per-connection encryption key, as it is obviously worthless to build it
right into the executable, correct? If that is the case, is there any reason
why a key can't be provided as a part of a password (from 9th character) or
even database name (e.g. C:\MyApplication\Data.FDB**encryptionkey)? That way
Firebird itself could reasonably claim security ("we are using
as-yet-unbroken AES, with the key supplied by the user at connection time")
and while it wouldn't be perfect, it would certainly be something better
than the nothing we have now.

> I use NTFS encryption on my laptop, and run the Firebird service under
> an account that has access to the database (my account does not have
> this access). I can not (without knowing the password and logging in
> as the Firebird user etc) view the contents of that file.
> Of course, as someone who knows the SYSDBA password, I can make a
> backup and view that in a hex editor.

Or someone who has administrative privileges (=everyone who has physical
access to the machine) and knows that it is enough to replace the security
database with his custom one.

Pepak