[PATCH] Introducing Zero-Knowledge user authentication

[Andreas Gaupmann]

Hello!

On Thursday 24 November 2005 11:47, Darren Tucker wrote:
> I'm not qualified to comment on the crypto aspects nor on the prospects
> for inclusion.  
>
Can you give us some advice on how to achieve or suggest such an inclusion? 
Who are the people we can ask about it?

> Obviously password or C/R authentication leaks authentication information
> to the server, but how does public-key?  (assuming the public-key
> algorithm has not been broken)  Are you referring to a server collecting
> signatures with various sessionids?
>
Basically yes. Conventional public-key methods of authentication leak 
information, because every signature contains some information about the 
private key which could be used to break the key. Zero-knowledge proofs of 
knowledge (of some private key, in our case) on the other hand yield nothing 
but their validity. No matter how cunningly you choose challenge values and 
how often you run the protocol successively, you still know nothing more than 
that the prover knows the secret key.

There's nothing wrong with using public-key authentication in a practice, 
because it's highly unlikely that any adversary would know what to do with 
the information contained in public-key signatures. In theory, however, the 
difference is significant.

Look at it this way: Using zero-knowledge is a way to reduce the security
assumptions even further (to the basic "factorization is infeasible"), and I 
believe that it's worth to go the extra mile for that.

> From the patch, it looks like multiple rounds are required.  What impact
> does that have on the authentication times, particularly on high-latency
> links?
>
We have not yet made any benchmarks that allow an objective comparison of the 
authentication times needed by the different user authentication methods. We 
are working on it. The authentication times with ZK were short during the 
tests of our patch and no annoying delays were encountered.

> You use the string "oo-zk" in the SSH protocol to identify the publickey
> mechanism you implement.  Unless this has been registered with IANA you
> should use a local method (ie "oo-zk at yourdomain.org") as specified in
> section 6 of the "SSH Protocol Architecture" document.
>
The string "oo-zk" ist only used as new type for the ssh-keygen. Do you mean 
the name of the authentication method in the Authmethod structure? We have 
changed that name now from zk at cms.ac to zk.

> The OpenBSD patch on your page includes all of the *.orig files, which
> makes it hard to read.
>
> Some of the files you add are under the GPL.  This isn't a problem while
> you're publishing it as a patch, but it would prevent it from being
> incorporated.
>
> You also have some minor errors in the patch (use of C++/c99 "//" style
> comments, declarations after code eg in key_fingerprint_raw()).  While
> some compilers will permit those, some won't.  There's also some
> whitespace-only changes which are unnecessary.
>
All these things are fixed now. We are constantly learning. The new patches 
can be downloaded from http://zk-ssh.cms.ac/

Thanks for your opinion and suggestions.

Regards
-Ulrich Zehl
-Andreas Gaupmann

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20051129/ffdc3500/attachment.bin