Hi Les,

The use of the Public / Private key pairs is simply for the separation
of users from one another. By using the key pairs for each user you
have the ability to grant / revoke permissions on a table by table
basis, or alternatively remove a user from access completely without
interrupting any other users of the system.

In essence, if you were to use a single AES key as the access code for
all users, say for example they type in a username / password and get
the AES key back in return, you have the problem of how to secure that
AES key. Where would you store it? By using the public / private key
pairs you dont have to worry about that problem because the only
exposed information is able to be publicly exposed. In this way you
can store any AES key or keys or data with a public / private key
pair.

The question then becomes why not use the public / private key pairs
as the primary means of encrypting all the data. There are two reasons
for this, the first being speed. Public / Private key encryption is
much slower to operate than symmetric encryption such as AES or DES
etc... It is theoretically possible to operate this way, but the
'horsepower' needed to do it in a timely manner for any significant
amount of data becomes a serious problem, even with current hardware.

The second reason is that you need to keep a 'central' copy of the
data available to be worked with for each user. If you use Public /
Private to encrypt this data you would require that each user has a
unique copy of the data as only their key pair could properly would
with that encrypted copy.

In short then, the basis for using the two schemes together is simply
one of practicality. We use the public / private key pairs to secure a
unique (user specific) copy of the 'central' AES key(s) that are
needed to get at the data. Each user logs in, their private key
generated from their password and username, decrypts the AES keys as
needed to access the data they are allowed to access. When you need to
remove a user from the system you can remain confident that that the
data will remain secure and simply remove the users username /
password from the system and not disrupt any other user in the system.

In theory you could also use AES or another symmetric cipher as the
means of securing the other AES keys. The condition being that you
still maintain the separation between the users username / password
key, and the key(s) needed to get at the data. If you do this it can
work fine, but you will lose the ability to operate with things like
secure tokens and such which typically work with certificates and
asymmetric encryption schemes. If you dont need / want the option to
employ tri-factor security then you can go with the more simple
username and password only. You would need to make some sort of check
in the authentication system / login so that the app knows if the user
has entered the correct data of course, same as before, then just make
sure that a copy of the tables AES key is encrypted for each user with
the users AES key. I think this should pretty much work the same for
you if you dont need the extra authentication of a smart card / token.

Is this what you were asking? I hope I understood you correctly. If
you need more info just let me know :-)

Cheers

The Frog