On Sunday 23 July 95, at 14 h 45, the keyboard of Tatu Ylonen <ylo@cs.hut.fi> wrote:

People have also suggested using the Photuris protocol that is part of the IP Security work being done at IETF (ftp://www.cnri.reston.va.us/internet-drafts/draft-ietf-ipsec-photuris-02.txt ).

The basic idea behind the protocol goes roughly like this: 1. Exchange session keys using Diffie-Hellman 2. Each side sends a signature of the Diffie-Hellman exchange (the signature can be with any of a number of algorithms; RSA and Elliptic Curve systems have been defined).

If this were adapted to ssh, the protocol would look roughly like this: 1. Exchange session keys using Diffie-Hellman 2. Each side sends a signature of the Diffie-Hellman exchange by its host key 3. RSA and Rhosts authentication requests would include a signature by the requesting key.

This would get rid of the server key and the need to regenerate it, because the diffie-hellman exchange already prevents decrypting old conversations. The challenge-dialogs could be avoided (unless they are needed for performance reasons to avoid unnecessary signature computations).

One could also eliminate RSA in future and start using some other public key cryptosystem if desired. The Diffie-Hellman patent and the generic public key patent expire in 1997; the RSA-patent does not expire until about year 2000.

Anyway, this would be a major change that probably cannot easily be made compatibly. Maybe an incompatible ssh-2.x? Anyway, I don't want to rush into making major changes in the protocol.

I would very much like to hear comments on this approach.

Tatu

Stephane Bortzmeyer Conservatoire National des Arts et Metiers bortzmeyer@cnam.fr Laboratoire d'Informatique 292, rue Saint-Martin tel: +33 (1) 40 27 27 31 75141 Paris Cedex 03 fax: +33 (1) 40 27 27 72 France "C'est la nuit qu'il est beau de croire a la lumiere." E. Rostand

On Mon, 31 Jul 1995, Matthew Ghio wrote:

Tatu Ylonen <ylo@cs.hut.fi> wrote:

...

The basic idea behind the protocol goes roughly like this: 1. Exchange session keys using Diffie-Hellman 2. Each side sends a signature of the Diffie-Hellman exchange (the signature can be with any of a number of algorithms; RSA and Elliptic Curve systems have been defined).

I've been playing with the cryptotcp program available from utopia.. It has some bugs but works pretty well, if you don't mind waiting 20-30 seconds at the beginning. It does a Diffie-Hellman exchange and 3DES over telnet. How hard would it be to add some sort of authentication to this program?

Yes, I'm interested too, also because cryptotcp looks like a good candidate as component of my "SafeSox" pet project, to make unmodified TCP applications secure. Apparently, a sockd daemon could be easily modified to open encrypted TCP connections to remote cryptod daemons, instead of targeting remote servers directly. The next logical step would be a Winsock (or Mac) version of that cryptified sockd, to be run on the same PC where the applications live (not everybody has a UNIX box on the same network). No modifications would be required in cryptod: Unmod. --- [socksifying DLL] === [crypto-sockd] ~~~~ [cryptod] +++ [server] Winsock Client --- = local API call === = local SOCKS connection (same network or same machine) ~~~ = cryptotcp connection across the Internet +++ = cleartext TCP connection on the same network or same machine Another area where I would appreciate analysis by someone more competent than myself is cryptotcp's random key generator. Even though the randomizer (in random.c) is called several times, stirring in the pool also quantities of entropy depending on the time spent during the establishment of the TCP connection, I doubt that the total resulting entropy can be that high. Perhaps, adding some purely local data a' la randseed.bin (not available to an eavesdropper) would reduce the risk of the scheme being brute-forced.