Secure anonymouse server protocol: comments please

[paul@fatmans.demon.co.uk]

The following is a very sketchy plan for a secure protocol for an 
anonymous server which allows replies without storing a recipient 
database in the clear.

To send a message:

The sender first exchanges keys with the sever (public key 
cryptography assumed), the server now has the users key and the user 
the servers.

The user sends the server:

The recipient for the message
the message itself
a password previously agreed
The users ID on the server

The server decrypts to get the above back in plaintext, then it 
encrypts the ID & the users address with a random session key and 
stores it in the database. notice nothing is stored in the clear
the server now encrypts the session key with the senders public key, 
and fowards it to the sender of the original message.
now finally the server sends the message onto the intended recipient 
in plaintext (who must also have exchanged keys with the server) along 
with the ID of the sender encrypted with the servers public key.
the recipient responds with his reply, and the ID of the sender still 
encrypted in the servers Public key

The server stores this

When the user (the original sender) wants to pick up his mail after a 
couple of days he sends the server his ID encrypted with the servers 
public key, the server compares this with all of the encrypted IDs in 
the database and when it finds a match it fowards the corresponding 
mail to the original sender of the first message.
Thats all folks.

This system has 1 huge fault, we can encrypt a uses ID with the 
servers public key to see what his ID in the encrypted database is 
and therefore identify him, maybe we need two seperate server public 
keys, and when IDs come in encrypted with key1 (the one it releases) 
it decrypts with secretkey1 then encrypts with publickey2 (the one it 
keeps secret)

or maybe we can just hash and sign the IDs in the database?

as I said it`s very sketchy, I made most of this up as I wrote it so 
if you must tear it to pieces please do so constructively, it could 
be the route to a secure system....

   

  Datacomms Technologies web authoring and data security
     Paul Bradley, Paul@fatmans.demon.co.uk
       Http://www.fatmans.demon.co.uk/crypt/
         "Don`t forget to mount a scratch monkey"

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6

mQCNAjH9j+cAAAEEAMBvREiQR0ot9dFCO0TiSCSunAYLv2g1Bc6I3bz8FzKXNH53
6mieJf/W4rD+CxJpT0q9RQaaoRtkHJLwbjfK2il3D7mEahMAyqvF/xRJNqkXfhM3
sRJM0Jh43l+W0M5vwokbEbk25/bxWWGspTsLD3YHbzKnG6pOcL5OPIRbv66xAAUR
tCdQYXVsIEJyYWRsZXkgPHBhdWxAZmF0bWFucy5kZW1vbi5jby51az4=
=riHc
-----END PGP PUBLIC KEY BLOCK-----