> Please, please, please! Please be noted that not everybody tries to use
> encryption where obscurity is the need, encryption does serve it's own
> serious purpose, Stop changing topic!

Sorry if I repeat things that were already discussed here, though I
believe that this was not posted here.

The database encryption was already discussed between Dmitry Yemanov,
Vlad Khorsun, Alex Peshkov and myself one or two years ago. The
architecture was pretty similar to the one presented by Jim in his
second email, only that Broker was considered to be the same process as
Server.

(I will use Jim's terminology here)

The outcome of the discussion was that as long as client cannot check
the authentity of the Broker process, it should not communicate with it.
That can be done via certificates. But assuming that certificate is
stored on the file system, admin has to ensure that original binary
accessing it is also trustable. Also, the Broker (as well as Server)
would need to ensure that the process is not being compromised, before
it accesses the database encryption key (e.g. signed binary).

We did not find any possibility to easily produce Firebird binaries (I
mean time/money) that would be able to ensure its authentity (signed
binaries with "hacker protection") and it was decided to leave this
market to a not-yet-existing commercial company.

IIRC, the idea with encryption plugin was also discussed, same logic re.
signed binaries applies. But implementing an API for encryption is
definitely doable, however was not the project's top priority when we
(devs) and sponsors discussed the roadmap.

But sure we (project) are open to any contribution (code, developers or
money, code or developers preferred) that would provide the encryption
plugin API. The signed binaries would, most likely, still be out of
scope for the project, but a simple plugin which would require admin to
type the password to access the database encryption keystore on server
startup is thinkable.

Roman