On 11/14/10 21:39, Jim Starkey wrote:

> Fixing Firebird security isn't as simple as supporting encryption
> plugins because plugins can't address the key distribution problem.
> Addressing the problem requires changes to the client, the protocol, and
> the server. Complicating the solution is the honorable tradition of
> allowing older clients to communicate with newer servers

When we talk about security enhancement on server this must be optional.
And sooner of all default (secure default) should be "no".

> and vice versa.
>
> The only responsible path is to propose, critique, and evolve a security
> architecture until there is consensus that it is good enough, then
> devise a strategy to implement it.
>
> I'm going to describe the security architecture I'm using in NimbusDB as
> a starting point. The key element is that clients generate one-time
> session keys that are securely transmitted to server. Whether the key
> only encrypts authentication credentials, all communications, or the
> database file at page level can be discussed separately.

// ...............................

> Line protocol consists of four byte message lengths followed by
> encrypted gook, rounded up to a multiple of the encryption algorithm's
> blocksize. Encrypted gook embedded in character data is encoded in base64.
>
> Guys, this is not plugin stuff.

I agree with all said here, except last phrase. Certainly, firebird must
extend remote protocol to support encryption and help with key
management. But let me try to rewrite your architecture in plugin's terms:

1. Server invokes line crypt plugin to generate key pair at startup time. If different crypt plugins require different types of key, all required key pairs are generated.
2. On first connection to a server, the client is given the server's public key(s) and a list of supported plugins for it(them).
3. The client selects an algorithm and calls crypt plugin which generates a one-time session key, encrypts the algorithm type and session key using the server's public key and returns that data block to the client, which sends it to the server.
4. The server invokes plugins one after another to try to decrypt data from the client. If some plugin (RC4, AES-128, AES-256 or any other) is able to decrypt data from client, secure communication is established.

I.e. on my mind use of crypt plugins do not contradict with security architecture, but makes it better.