04.11.2010 18:37, Sijun Kang wrote:

> BTW, talking about justifying the developing effort in Firebird developer
> group, the reason I brought up the "old" issue is because I found that some
> encryption-related code have already been in the Firebird code base since
> 2003 (based on the comment I read in the source files). I assume that the
> architecture had been adjusted at that time to enable this effort as well.
> If nothing existed in current code base, I would not say a word on this
> giving all other priorities in core Firebird development :)

The code is there since the Borland era. I've completed and tested it at
some point during the v1.5 development. It's a plugin-based page-level
encryption with the user specified key. Yes, it basically works,
although some adjustments would make this feature more appealing. The
major issue, as already mentioned here, is the key management.

The current implementation may be more-or-less okay for the embedded
database access. It's possible to steal the key by substituting the
original Firebird embedded engine with a compromised one, or by
injecting the hackery code inside the address space, but there are
solutions (not necessarily free of charge) to prevent that for those who
really care about the absolute (we know it's a fake, but anyway)
security. This is the only solution we can offer out of the box now and
it's mostly targeted to distributed applications.

For network applications, an over-the-wire encryption must be added to
keep the key secure. Alternatively, keys could no longer be required to
be sent from the client side, but instead be loaded from the server side
storage. Generally, the "protected server" concept puts different
requirements and they may go quite far from the Firebird controlled
environment. Some day in the past, there was an attempt (in this list)
to put all the requirements together and offer an universal solution
expected to fit all major usage scenarios. IIRC, nobody even commented
it, supposedly because it looked over-complicated.

So I don't really believe we might offer something suiting everybody's
needs. My personal position is that we either offer the current solution
(likely slightly improved) for embedded/local applications (actually,
it's about 90% of those asking for encryption) and say sorry to
everybody else, or we forget about this topic at all.


Dmitry