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

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 30 Mar 2005 15:06:56 -0500

I've just noticed:

	http://www.ietf.org/internet-drafts/draft-harris-ssh-arcfour-fixes-00.txt

and Ben recently mentioned:

	http://www.ietf.org/internet-drafts/draft-harris-ssh-rsa-kex-01.txt

Is there any interest in either of these as working group items?

rsa-kex is a weaker kex (as it allows the client to completely determine
the session key); arcfour-fixes is a stronger version of the existing
arcfour cipher.

I don't believe either of these is in conflict with existing work in the
WG; the path of least resistance may be for Ben to submit these as
individual submissions to the IESG.

						- Bill

---

From: Ben Harris <[email-masked]>
Date: Thu, 31 Mar 2005 00:09:17 +0100

>individual submissions to the IESG.

I'm happy to do that if there's no interest in turning them into WG drafts. 
I'd kind of like to know whether anyone thinks they're worthwhile at all,
though.

>the session key);

I'm not convinced that this is a problem, since K gets hashed with
server-supplied data at least once before it's used, so unless the client
can break the hash function they can't usefully determine the exchange hash
or session keys.  If someone can explain why there's a problem here, I may
be able to work out a way around it.

Of course, being weaker isn't the point of rsa-kex; using much less CPU time
on the client side is.

-- 
Ben Harris

---

From: der Mouse <[email-masked]>
Date: Wed, 30 Mar 2005 19:07:01 -0500 (EST)

> 	http://www.ietf.org/internet-drafts/draft-harris-ssh-arcfour-fixes-00.txt

I've implemented these, and also [email-masked],
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.

> 	http://www.ietf.org/internet-drafts/draft-harris-ssh-rsa-kex-01.txt

I haven't implemented this yet, but I certainly intend to.

> 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.

Note that there is no point trying to defend against a malicious
client producing weak secrecy, since the client has direct access to
the decrypted data stream and can leak it any way it pleases -
especially since the protocol is full of opportunities for covert
channels, including covert channels between an endpoint and a passive
eavesdropper.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       [email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: Ben Harris <[email-masked]>
Date: Thu, 31 Mar 2005 20:53:58 +0100

>of the keystream.  I'd be happy to do interop testing with anyone else

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.

>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.

>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