--
At 02:36 PM 7/22/2000 -0400, David Jablon wrote:
> James,
>
> The approach of splitting the key into low and high entropy parts is
> obvious, but you're solution is probably not obvious to very many
> people. At least it wasn't to me.
>
> Can you elaborate on the points below?
At 09:50 PM 7/21/00 -0700, James A. Donald wrote:
> > On reflection, the obvious solution to this is for the user to
> > have his possibly low entropy key p, and the server to keep for
> > him a high entropy key q.
> >
> > 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.
> 1) How does the server establish the user's identity?
>
> 2) Is the DH channel secure against a middle-man because it's
> authenticated?
I made the following up myself, on the spur of the moment, so unless it
corresponds to something someone else has already done, it may well be
snake oil.
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.
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.
James A. Donald:
> > If the user chooses a low entropy key, he is secure from attack by anyone
> > except the server, and if he chooses a high entropy key, he is secure
from
> > attack from anyone.
> That p+q trick might be nice, where I suppose the user interacts with
> the server to get a partial "signature". But there seem to be a wide
> variety of other ways to split a key into low and high entropy parts.
> Is there an advantage in your scheme over simply delivering q to
> the user?
My concern is that if the user access and localy stores q on a variety of
machines, sooner or later q may be revealed, even if q is only stored in
memory and ony for the duration of the logon session.
--digsig
James A. Donald
6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
Ip1QfP2znuppVC0+6om+LoS5kstSqZVb3EZ5gQIR
4q7yZSBMti4TtaST3n0eS90EpGqfMM+HQhPfk1LhY
