how to use the gnupg for authenticated logins
Carl L. Gilbert
Sun Aug 10 02:54:02 2003
On Sat, 2003-08-09 at 13:55, Neil Williams wrote:
> 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 clien=
> > > know that this is a suitable random key and not an attacking random k=
> > > 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 ca=
> > be gained by a false server sending a key because the client would neve=
> > be able to decrypt it.
> A random key cannot verify the server to the client. Your authentication =
> only one-way.
read it again, slowly. "server can auth the client only"
> The random key has to be encrypted to the client key, which is public. An=
> can encrypt a random key to a public key of a client. As the random key i=
> untrusted, the client has no way of knowing that the real server has sent=
again, client does not care. This is the server authenticating the
client. Not vice versa. The server is just giving the client a
temporary random key so the client can send back the password encrypted.
> A false server using a spoofed IP can send a random key encrypted with th=
> of the client - the client imports the key and encrypts the token back to=
> false server - classic man-in-the-middle attack. The false server may not=
> 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 beli=
> it is the real server and starts using the services.
OK, I am going to stop here because I think I agree there is a flaw.=20
The flaw is in my description. This system is actually not using public
key encryption. The so-called password is actually a key that both the
client and the server know. It was shared when they first authenticated
each other, manually.
> You can't encrypt a random key to itself, no-one would be able to decrypt=
> 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 k=
> 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 ke=
> publicly available, the attack is in motion.=20
didn't say this. The random key is sent encrypted to the client, using
the clients public key. and yes anyone could send a key to the client
encrypted to him. and he would decode it. then use that key to encrypt
a message back to the server. this would successfully authenticate the
client. but i dont think i authed the server.
> If you make it a random key encrypted with a known server key, you have t=
> distribute the server secret key - not healthy.
> If you don't encrypt it, you have to verify the client - anyone can encry=
> a random key sent in plain text - and you still haven't verified the serv=
yes, haven't verified the server.
> > > If the key can be trusted, why send it at all? It must be known to th=
> > > client to be trusted, so the client doesn't need the key. Use the 'se=
> > > 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 clien=
> trust in the authentication.
> > The decryption is as it is today, passphrase optional. Your first fals=
> > 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 b=
> > > The server sends the token to the client, encrypted with the trusted
> > > client key. Once this is verified, the process can be automated from =
> > > client end:
> > >
> > > 1. Client requests connection.
> > > 2. Server sends a token encrypted with the trusted client key. (Fail =
> > > 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 ser=
> > > 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 to=
> and the keyID's used to encrypt them. Upon successful authentication, the=
> token is invalidated by the server and deleted from the outstanding list.=
> Together with the need for successful verification of the client signatur=
> the returned token, this should mean that a recorded token is useless as =
> 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 rec=
> 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 G=
> 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!
well, I failed to properly describe it. its not a public key encryption
system. and I just remembered that. When they agree they know each
other, they exchange a password. that password is like a salt of sorts,
and without it, neither can understand the other.
so its not public key because they both are using the same key to
encrypt to, sort of.
> > 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 chan=
> and any MITM attack can be detected. SSH still leaves the possibility of =
> client connecting to a false server that first time. Your proposed random=
> 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 su=
> 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 dat=
are you saying their is a problem with ssh? I disagree. The notion of
'first time' is really just a notion of how you get the key you trust.=20
It does not have to be by connection to the server. It could be from
any trusted source.
For me, the fingerprint could be on the receipt in my package when I
receive my merchandise from the store. Or it could be displayed on the
website. Or I could walk into the bank and pick up a copy, etc.
"Then said I, Wisdom [is] better than strength: nevertheless the poor
man's wisdom [is] despised, and his words are not heard." Ecclesiastes
GnuPG Key Fingerprint:
82A6 8893 C2A1 F64E A9AD 19AE 55B2 4CD7 80D2 0A2D
GNU Privacy Guard http://www.gnupg.org (Encryption and Digital
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
-----END PGP SIGNATURE-----