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

[der Mouse <mouse%Rodents.Montreal.QC.CA@localhost>]

>>> 	http://www.ietf.org/internet-drafts/draft-harris-ssh-arcfour-fixes-00.txt
>>> 	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.

Well, I have what I think is an implementation of both kex methods from
rsa-kex-01 now too.  My code interoperates with itself, of course, but
I'd like to do interop testing with others' implementations of any of
these algorithms.  Anyone game?

>>> rsa-kex is a weaker kex
>> Well, it's weaker in some respects,
> [D]iscussions 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.

I'm not sure this buys you anything of significance.  Even granting all
the above, what can go wrong if a client (or two clients in collusion,
which amounts to the same thing) gets two sessions with the same
session ID?

It allows the client to get the server to sign the same data twice,
which could be a weakness if the host key algorithm involves random
elements in signing, and is weak against such an attack.  ssh-rsa does
not involve any random element, so the same data signed by the same key
gives the same signature and, perforce, no new information.  ssh-dsa
does involve random data in signing; I haven't looked at it enough to
have more than a wild guess whether it leaks information if the same
data is signed twice with the same key.  (If forced to guess, I would
guess it does not; the designers of DSA had plenty of competence on tap
to build something strong against that if they wanted to, and it's an
obvious potential attack.)

If the session ID *and the shared secret* are the same, so will all the
derived keys and IVs, which means that for some ciphers, like arcfour,
the resulting connection is insecure against passive attackers (since
it then involves encrypting different data with the same keystream).
But as I pointed out earlier, a client that wants to leak session data
to a passive listener has lots of easier methods available.  Even if it
doesn't want to leak it directly, the protocol makes no effort to
prevent covert channels from either endpoint to passive snoopers - and
such a client could just leak the keys and IVs directly, thus letting
the snooper read the traffic without taking the risk of alerting the
server that arranging two connections with the same session ID does.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse%rodents.montreal.qc.ca@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B