> And also the cost of 'processing' encrypted data so that index files do not
> contain information that would help un-encrypting?

Sure.

> Why not simply use the password protection provided by and external packing
> program. My own backup process stores it's archives using .gz and that can be
> password protected.

The case that was mainly discussed here was that our database is
deployed in a hostile environment - you cannot trust admin, you cannot
trust OS, you cannot trust the wire.

> It is the design of the 'architecture' of a complete solution that is important,
> and simply grafting encrypt/decrypt in some parts of the system is not the
> solution. As others have said ... you need to be able to manage the keys and the
> like which is where existing OS solutions may provide a much more sensible
> solution. And one that will be complicated by needing to work cross platform.
> Have a look at the problems the DVCS systems are having providing a generic
> solution to security between Linux/Unix, Mac and Windows ;)

Exactly. That's why I argue that we (project) do not really want to go
that way (providing something very simple, like XORing the pages or ECB
encryption on page level + SSL/TLS for the wire).

But if there is somebody having such requirements and resources to
implement it, we should be their first choice of the database engine to use.

Roman