[7546] in cryptography@c2.net mail archive
Re: Weak user keys, strong servers.
daemon@ATHENA.MIT.EDU (David Jablon)
Mon Jul 24 09:39:22 2000
Message-Id: <3.0.5.32.20000724074704.009bf7b0@world.std.com>
Date: Mon, 24 Jul 2000 07:47:04 -0400
To: "James A. Donald" <jamesd@echeque.com>
From: David Jablon <dpj@world.std.com>
Cc: "James A. Donald" <jamesd@echeque.com>,
"'cryptography@c2.net'" <cryptography@c2.net>, coderpunks@toad.com
In-Reply-To: <4.3.1.2.20000723085253.02380a20@shell11.ba.best.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 09:48 AM 7/23/00 -0700, James A. Donald wrote:
...
> > > The public key is G^(p+q).
> > > The secret key is p+q, and the user never seeks to find out q.
> > > The server establishes the user's identity by verifying that he
> > > knows p corresponding to the shared secret G^p. It then, on a
> > > secure channel established by DH, provides the user with P^q,
> > > where P is whatever the user requests, as often as the user
> > > requests it.
...
>When the user created his account, he informed the server of G^q through
>https. He knows he gave this information to the real server thanks to the
>usual https mechanism, and since the primary job of the public key is to
>perform a function similar to that of a video answering machine, the server
>does not need to verify the users true name, merely establish that the user
>is the same person as created the account.
>
>The object of the protocol is to ensure that the client knows he is
>communicating with someone who knows G^p, and the server knows it is
>communicating with someone who knows p
>
>In this it differs from SPEKE, where both know p.
This sounds like the same goal as Augmented-EKE, B-SPEKE, SRP-3, and AMP.
These protocols are currently referred to in the P1363 effort by the catchy phrase:
"password-based authenticated key exchange in an asymmetric trust model."
>In subsequent logons the user sends the server his logon name in the clear,
>The server responds generates a random number b, and sends the user
>G^b. The client similarly generates a random number c and sends the server G^c
>
>The client then generates the secret number (G^b)^(c+p)
>
>The server then generates the secret number [(G^c)* (G^p)]^b
>
>This number is then used as the symmetric secret key for client server
>communications until the user logs off.
It looks interesting so far. But it's important to show what happens next.
In the session encrypted with the key K = G^bc * G^bp, if the server sends
back verifiable plaintext symmetrically encrypted under K,
it can enable off-line attack.
-- dpj
---------------------------------------------------
David P. Jablon
dpj@world.std.com
www.IntegritySciences.com
