Re: draft-harris-ssh-rsa-kex-02 and a possible future change

[Ben Harris <bjh21%bjh21.me.uk@localhost>]

In article <200507071457.KAA01707%Sparkle.Rodents.Montreal.QC.CA@localhost> you write:
>> I've uploaded a new version of my RSA KEX draft. 
>> <http://www.ietf.org/internet-drafts/draft-harris-ssh-rsa-kex-02.txt>
>
>> 1: Using SHA-512 in place of SHA-256.
>
>I'm not sure I like this.  SHA-256 is reasonably good for 32-bit
>machines; SHA-512 (and SHA-384) are basically 64-bit algorithms,
>calling for eight 64-bit temporaries in their core loops.
>
>I think this change will disproportionately hurt exactly those machines
>where your kex is most beneficial - old, slow, half-lung machines,
>which are usually 32-bit.

You're right.  On a convenient slow machine (50MHzish ARM7500FE), a 2048-bit
RSA public operation takes about 1/3s and a 1024-byte SHA-512 takes about
1/2s.  I haven't got a convenient SHA-256 implementation, but looking at the
spec it's a lot friendlier to small systems.  I'll reverse that change.

>> 2: Including the encrypted secret in the data hashed to generate the
>>    exchange hash.
>
>My reaction here is basically "shrug".  I don't really see the hazard
>in the client managing to generate two sessions with the same exchange
>hash in the first place.

I don't think there's a hazard there, but there is one if the client gets to
co-operate with (or be) a server using a KEX method that lets the server
choose the last input to the hash.  Such a KEX method would be approximately
as sane as rsa1024-sha1-draft-01, so I can't safely assume that no-one will
ever deploy one.  Indeed, I suspect that the currently-defined KEX methods
might qualify depending on the host key formats in use.

-- 
Ben Harris