Re: Ben Harris's individual submissions: arcfour-fixes and rsa-kex

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

In article <200503310027.TAA04837%Sparkle.Rodents.Montreal.QC.CA@localhost> you write:
>> I've just noticed:
>> 	http://www.ietf.org/internet-drafts/draft-harris-ssh-arcfour-fixes-00.txt
>
>I've implemented these, and also arcfour-64k%rodents.montreal.qc.ca@localhost,
>which is just like stock arcfour except it drops the first 65536 bytes
>of the keystream.  I'd be happy to do interop testing with anyone else
>who's done any of them.

I've got an untested implementation of my ones for PuTTY (client-only of
course).  I haven't yet made the patches available anywhere, but I intend
to.

>> and Ben recently mentioned:
>> 	http://www.ietf.org/internet-drafts/draft-harris-ssh-rsa-kex-01.txt
>
>I haven't implemented this yet, but I certainly intend to.

I've got client and server implementations of the -00 version in OpenSSH,
and Simon's done an independent client implementation of it for PuTTY.  I
don't think either of us has yet updated for -01.

>> rsa-kex is a weaker kex (as it allows the client to completely
>> determine the session key);
>
>Well, it's weaker in some respects, perhaps, but the parenthetical note
>is false; see the last paragraph of section 8 of the draft.

This is true, but discussions of SHA-1 have convinced me that there's a
slight weakness here that I should perhaps guard against.  Because the
client can see all the other input to the exchange hash before it generates
K, if it's got a working collision attack against HASH it can create two
sessions with the same session ID.  This isn't the case for DH KEX, though
there the server could do the same thing by varying its host key (at the
expense of having to convince the client that the new key was valid).  While
my choice of hashes is designed to make brute-force birthday attacks about
as expensive as cracking the transient RSA key, this doesn't take account of
the propensity of MD4-derived hashes towards better-than-brute-force
collision attacks.  I'm still undecided whether it's worth trying to avoid
this by any means other than using stronger hashes.

-- 
Ben Harris