On 11/14/2010 5:38 PM, Olivier Mascia wrote:

> Le 14 nov. 2010 à 19:39, Jim Starkey a écrit :
>
>> Here is the architecture:
>>
>> 1. Servers generate RSA key pairs at startup time. They may, if they
>> wish, generate new key pairs anytime they wish.
>> 2. On first connection to a server, the client is given the server's
>> public key and a list of supported encryption algorithms.
>> 3. The client selects an algorithm, generates a one-time session key
>> using a secure random number generator, encrypts the algorithm
>> type and session key using the server's public key, and sends the
>> gook to the server
>> 4. The server decrypts the gook with its private key.
> Well, this is SSL/TLS principle. Wouldn't it be preferable to re-use SSL/TLS? What rationale commands to design and implement a private scheme for exchanging the initial random session keys?
>

A couple of reasons. One is for configurable security -- requirement
encryption for connections outside the firewall while skipping it
inside. Another is to save the administrator from the hassle of
installing, configuring, and administrating TLS and the necessary server
certificates. Integrating the code into Firebird isn't at all difficult
and means that a user has only one thing to install and nothing to
integrate. Would TLS be mandatory? If not, there would need to be
either separate kits of TLS stubs to emulate the secure socket API
against ordinary sockets. If it were simple, it's hard to understand
why it hasn't already need done. If it isn't simple, the integration
cost has to be balanced against inclusion of crypto code into mainline
Firebird.

If you feel strongly, why not put together an alternative architecture
using TLS for comparison?