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?
>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?
Best regards,
David
---------------------------------------------------
David P. Jablon
[EMAIL PROTECTED]
www.IntegritySciences.com
