> What I see as an important drawback here is that once you
> mount the volume, your database becomes visible (unencrypted!)
> to the entire OS and possibly to other users on the system. I
> would strongly prefer that only the db engine can see and
> serve the unencrypted data.

It is not a matter of the entire volume becoming decrypted,
but yes the facility to decrypt is running. However you need
to remember that this is a virtual disk, it can be formatted
with NTFS (or whatever) and usual operating system access
controls applied.

The encryption process itself must also be protected. See the
post by Myles that indicates one of many possible attacks that
can be applied against unprotected systems. The encrypted
data may be safe but the encryption process can be vulnerable
to key-loggers, trojan software etc etc etc - so you MUST
protect the system from such attacks.

Having data encrypted is useful to protect you against after
hours break-ins and theft of equipment. Having backups
encrypted is really useful because it allows you to just
discard old media without worrying about what someone may be
able to extract from it. But encryption is NOT going to
protect you from every possible form of attack, put very good
encryption in place and the attacker will try and go around it.

...

> I understand that security is a complex matter and very
> difficult to do properly, on the other hand I believe that
> 90% of the users would be happy with even a non-100%-perfect
> solution - even a relative security should be better than no
> security at all, and often the data you'd like to encrypt is
> not worth the efforts someone should invest in breaking it.

In an open-source product non-100%-perfect security generally
means completely broken... you cant even pretend that secrecy
may protect you. As soon as a hacker decides it is worth
breaking he can make that solution available to everyone, all
you will have achieved is giving people a very false sense of
security.

As soon as those people that monitor products for security
holes discover the problems in Firebird their websites will be
plastered with "SECURITY ALERT" messages for Firebird. Anyone
reviewing Firebird will see those alerts and Firebird's
reputation will suffer - for no real benefit.

None of the above makes any comment about Oracle or Interbase
or other DBMS encryption services, I have not studied them.
Commercial organisations may be able to afford to hire experts
to help them implement their security correctly... I can only
assume that someone like Oracle would have done so.

To direct Firebird's very limited resources towards an
implementation that is both difficult and redundant (other
solutions exist) seems like a rather strange request to me.
It is not as though they have nothing else to do, there are
even other security issues to address.

--
Geoff Worboys
Telesis Computing