From: paul@fatmans.demon.co.uk
To: cypherpunks@toad.com
Message Hash: 3e3fe4b5b0e134ca53b1d1efa445e2f65461748fbb0f053b0c2a6cd717eb216b
Message ID: <841692281.5135.0@fatmans.demon.co.uk>
Reply To: N/A
UTC Datetime: 1996-09-03 04:04:09 UTC
Raw Date: Tue, 3 Sep 1996 12:04:09 +0800
From: paul@fatmans.demon.co.uk
Date: Tue, 3 Sep 1996 12:04:09 +0800
To: cypherpunks@toad.com
Subject: Secure anonymouse server protocol: comments please
Message-ID: <841692281.5135.0@fatmans.demon.co.uk>
MIME-Version: 1.0
Content-Type: text/plain
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-----
Return to September 1996
Return to “paul@fatmans.demon.co.uk”
1996-09-03 (Tue, 3 Sep 1996 12:04:09 +0800) - Secure anonymouse server protocol: comments please - paul@fatmans.demon.co.uk