Aage Johansen wrote:
...

> This may mean that without the ability to encrypt the
> database (or fields in the tables) we could find that
> Firebird is no longer a viable option. Sigh.

...

Where does a statement like this come from? You can already
encrypt the entire database with very strong encryption, I
have been doing it for years. I currently use Truecrypt
volumes, previously I used PGPDisk. Simple, very very
effective and still allows the engine to do all its normal
SQL tricks as if the data were not encrypted.

All my backup data is encrypted (not just databases) by the
simple expedient of backing up to a truecrypt volume.

For across-internet I use OpenVPN. I generally dont bother
encrypting LAN traffic but you can do that too if you want.

Aage also said:

> Disc encryption will not do (as far as I have heard).

...

The only justification I have ever heard for why disc or
volume encryption is not suitable is that key management is
a major PITA. This is the sort of excuse given my people who
do not understand security. Exactly the same sort of key
management would be required if you want encryption worthy
of the name to be available in Firebird.

Encryption is a very specialised field. Using a product
maintained by experts in the field, and tested by people with
a vested interest in the field, is the best way to get good
encryption. Much better than is likely to be achieved by
database experts trying to deal with encryption part-time (no
disrespect intended).


If you want something more than what I describe above then I
suggest you need to describe the requirements in more detail.
Government security and defence specific requirements are often
very intense, but I would suggest that Firebird has a whole lot
more wrong with it than encryption when it comes to those sorts
of requirements.


All this is about encrypting user-data by user-controlled and
managed measures. Encrypting meta-data is a very different
subject - covered in a separate article some years ago.

--
Geoff Worboys
Telesis Computing