You can use a shared secret to encrypt initial connection transmission.

ie.

When you call the create database api, you specify the public and
private key.
When you connect to the database, the connect information, except for
the users name, password and public key, is unencrypted.
The server uses the connect information to attach to the database and
read the private key (which is in the database header) to decode the
public key, user name and password.
It then uses that information to finish the connection.

This means, that in order to break the security, the cracker, would need
a physical copy of the database, a valid client, a valid user name, a
valid password, a packet sniffer and a pretty good understanding of what
is involved (most people are totally intimidated by
encryption/decryption so they give up before they begin).

(this assumes the user information is kept inside of the database
itself)

This is a level of security that would keep the average hacker out of
the equation, and allow for some security in storage and transmission.

This is far from secure. BUT, it is better than what we have and should
not unduly slow down the server or make the datapackets so large that
the networks get saturated.

I am not certain that this is the best way to go, but, I have not heard
any other suggestions that would work without a total rewrite of the
security layer.

best regards

Dalton

Ann Harrison wrote:

>
> At 11:42 AM 5/30/00 -0400, Dalton Calford wrote:
> >This is a interesting problem.
>
> Isn't it?
>
> >If the connect/create api, included the passing of a key value (128 bit
> >or maybe as long as the page size - size to be figured out once all
> >things are considered) ...
> >
> >The only real method of decrypting such a system would be to try a brute
> >force attack on the database or guess the key.
>
> Or sit on the line, waiting for a connect packet.
>
> Ann
>