how to use the gnupg for authenticated logins

[Carl L. Gilbert]

--=-STGNHyf8Y4HJKDV+d7K6
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

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=
t
> > > know that this is a suitable random key and not an attacking random k=
ey?
> > > 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=
n
> > be gained by a false server sending a key because the client would neve=
r
> > be able to decrypt it.
>=20
> A random key cannot verify the server to the client. Your authentication =
is=20
> only one-way.
>=20

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=
yone=20
> can encrypt a random key to a public key of a client. As the random key i=
s=20
> untrusted, the client has no way of knowing that the real server has sent=
 it.
>=20

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=
e key=20
> of the client - the client imports the key and encrypts the token back to=
 the=20
> 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 beli=
eves=20
> it is the real server and starts using the services.
>=20

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=
 it.=20
> 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=
eys,=20
> 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=
y is=20
> publicly available, the attack is in motion.=20
>=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=
o=20
> distribute the server secret key - not healthy.
> If you don't encrypt it, you have to verify the client - anyone can encry=
pt to=20
> a random key sent in plain text - and you still haven't verified the serv=
er.
>=20

yes, haven't verified the server.

> > > If the key can be trusted, why send it at all? It must be known to th=
e
> > > client to be trusted, so the client doesn't need the key. Use the 'se=
cret
> > > 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.
>=20
> If the client cannot trust the server key, there is nothing for the clien=
t to=20
> trust in the authentication.
>=20
> > The decryption is as it is today, passphrase optional.  Your first fals=
e
> > assumption is now mushrooming.  You do NOT care about the random key.
>=20
> I do if I cannot verify that it belongs to the server I think it should b=
elong=20
> to.
>=20
> > > 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 ser=
ver
> > > 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?
>=20
> 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=
kens=20
> 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 signatur=
e on=20
> the returned token, this should mean that a recorded token is useless as =
soon=20
> 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=
ord=20
> and playback should be limited.
>=20
> > 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.
>=20
> That seems a long way off. These sites don't know anything about PGP or G=
nuPG=20
> and I can't see many offering the trade.
>=20
> > 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.
>=20
> So the real system has no means for the client to verify the server???
> I wouldn't touch it!
>=20

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.
>=20
> But SSH keeps to the same key - once verified, the key details don't chan=
ge=20
> and any MITM attack can be detected. SSH still leaves the possibility of =
the=20
> client connecting to a false server that first time. Your proposed random=
 key=20
> 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=
btle=20
> change in the URL and the client is talking to your competitor / enemy!
>=20
> Authentication needs to protect the client data as well as the server dat=
a.

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.


--=20
Thank you,


CL Gilbert
"Then said I, Wisdom [is] better than strength: nevertheless the poor
man's wisdom [is] despised, and his words are not heard." Ecclesiastes
9:16

GnuPG Key Fingerprint:
82A6 8893 C2A1 F64E A9AD  19AE 55B2 4CD7 80D2 0A2D
GNU Privacy Guard http://www.gnupg.org (Encryption and Digital
Signatures)

--=-STGNHyf8Y4HJKDV+d7K6
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)

iD8DBQA/NZfwVbJM14DSCi0RApVoAJ0WRoe7rHOTGQdUDv+/oVnREDnmVACfVej0
CZUT80mPHbJtL2ZJ5eLpE8A=
=pGjK
-----END PGP SIGNATURE-----

--=-STGNHyf8Y4HJKDV+d7K6--