On Sun, Jun 06, 2004 at 03:31:59PM -0400, der Mouse wrote:
> No, actually.  Go read the spec - a session key is generated, but it
> (a) is done in a fairly fast way (by hashing data derived from key
> exchange) and (b) is done by both ends.  It's the key exchange itself
> that's slow.

Ok. But there are operations in that process where the intel bignum assembly
stuff helps a lot.

If I do "ssh -v" into my LX there is a long pause between

---8<---
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 zlib
debug1: kex: client->server aes128-cbc hmac-md5 zlib
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
--->8---

and (like 20s later) this:

---8<---
debug1: Host 'XXXXXXX' is known and matches the RSA host key.
debug1: Found key in XXXXXXXXXXXXXXXXXXXXXX
debug1: ssh_rsa_verify: signature correct
debug1: Enabling compression at level 6.
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
--->8---

So you are right, the NEWKEYS stuff is fast, SSH2_MSG_KEX_DH_GEX_REPLY
takes quite some time.

I see a similar delay to all my various machines unless they are Intel
or use a proprietary compiler to build their sshd. Scaled by relative
CPU speed, of course.

One of these days I'll do the openssl bignum assembler stuff for ultra sparcs.
But probably zlib first.

Martin