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
[EMAIL PROTECTED]
www.IntegritySciences.com


Reply via email to