how to use the gnupg for authenticated logins
Sat Aug 9 19:53:02 2003
Content-Description: signed data
On Saturday 09 Aug 2003 4:53 am, Carl L. Gilbert wrote:
> On Fri, 2003-08-08 at 18:49, Neil Williams wrote:
> > On Friday 08 Aug 2003 10:10 pm, Carl L. Gilbert wrote:
> > > On Fri, 2003-08-08 at 14:08, Neil Williams wrote:
> > > server sends a random key encrypted.
> > Why a random key? How can a random key be trusted? How will the client
> > know that this is a suitable random key and not an attacking random key?
> > IP's can be spoofed.
> if its random, then you don't need to trust it by definition. That key
> is sent so that the server can auth the client only. no information can
> be gained by a false server sending a key because the client would never
> be able to decrypt it.
A random key cannot verify the server to the client. Your authentication is=
The random key has to be encrypted to the client key, which is public. Anyo=
can encrypt a random key to a public key of a client. As the random key is=
untrusted, the client has no way of knowing that the real server has sent i=
A false server using a spoofed IP can send a random key encrypted with the =
of the client - the client imports the key and encrypts the token back to t=
false server - classic man-in-the-middle attack. The false server may not=20
gain any information from the real server but if the client is fooled by=20
MITM, the false server could pick up all sorts of data as the client believ=
it is the real server and starts using the services.
You can't encrypt a random key to itself, no-one would be able to decrypt i=
Anyone can encrypt to my key, I will be able to decrypt anything sent=20
encrypted with my key. I cannot decrypt tokens encrypted with any other key=
random or otherwise. For the client to decrypt the token containing the=20
random key, the token must be encrypted with the client key. When that key =
publicly available, the attack is in motion.=20
If you make it a random key encrypted with a known server key, you have to=
distribute the server secret key - not healthy.
If you don't encrypt it, you have to verify the client - anyone can encrypt=
a random key sent in plain text - and you still haven't verified the server.
> > If the key can be trusted, why send it at all? It must be known to the
> > client to be trusted, so the client doesn't need the key. Use the 'secr=
> > message' (which might as well be random text) and encrypt that. The
> > client decrypts it, sends it back re-encrypted to the server key.
> see above. their is no trust in that key, servers benefit only.
If the client cannot trust the server key, there is nothing for the client =
trust in the authentication.
> The decryption is as it is today, passphrase optional. Your first false
> assumption is now mushrooming. You do NOT care about the random key.
I do if I cannot verify that it belongs to the server I think it should bel=
> > The server sends the token to the client, encrypted with the trusted
> > client key. Once this is verified, the process can be automated from the
> > client end:
> > 1. Client requests connection.
> > 2. Server sends a token encrypted with the trusted client key. (Fail if
> > no trusted key)
> > 3. Client can decrypt this token (preferably using a human entered
> > passphrase) and then return the token re-encrypted to the trusted server
> > key. (Fail if decrypted token doesn't exactly match text sent to the
> > client identified by the token.)
> can't this fall to a record and playback attack?
The token has to be a one-off. The random text in the token would only=20
authenticate one client and the server maintains a list of outstanding toke=
and the keyID's used to encrypt them. Upon successful authentication, the=20
token is invalidated by the server and deleted from the outstanding list.=20
Together with the need for successful verification of the client signature =
the returned token, this should mean that a recorded token is useless as so=
as the server receives the real one. A diverted token may be a different=20
problem - have to see if diversion could be defeated by the signature,=20
perhaps include a route/network address inside the signed token. A spoof=20
token cannot be created before the client replies, so the options for recor=
and playback should be limited.
> yes, not full automation. but like ms passport is using, or like
> browsers that use recorded passwords. My objective is to trade in a
> password for a PGP key. So every time I go to a new web board or new
> web store, I can trade the password they give me, for my PGP key.
That seems a long way off. These sites don't know anything about PGP or Gnu=
and I can't see many offering the trade.
> This is my feelings. I am actually telling about a true system that I
> have worked on that is used in cars. just to show how its done there.
So the real system has no means for the client to verify the server???
I wouldn't touch it!
> But not really recommending it because computers already have so many
> encryption systems. ssh is a dually authenticated and encrypted
> channel. Its basically what we want to mimic here.
But SSH keeps to the same key - once verified, the key details don't change=
and any MITM attack can be detected. SSH still leaves the possibility of th=
client connecting to a false server that first time. Your proposed random k=
would leave the client open to MITM EVERY time because the client cannot=20
verify that the server is the same one as before. A simple IP spoof, a subt=
change in the URL and the client is talking to your competitor / enemy!
Authentication needs to protect the client data as well as the server data.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
-----END PGP SIGNATURE-----