> > The only algorithm which actually has a real chance in 100Mbps
> > network is RC4 (or ARCFOUR).
> ...
> > As for implementation. SSH1 implementation isn't worth a dime, but it's
> > not really relevant as it's insecure to use any stream cipher with SSH1
> > protocol.
>
> Where can I find a good explanation of this problem? I've seen it
> mentioned in various sources, but I'm not much of a cryptanalyst...
The root of the problem is that SSH1 uses CRC32 as a message
authentication mechanism. It is fairly easy to subvert that. There
are published papers on how to modify data under any "xor"-type
encryption while maintaining its CRC unchanged (sorry, I don't
remember a reference off my head).
This basic flaw leads to other, more serious issues if you allow
stream ciphers in SSH1. Some of them have been described in a paper
by Antti Huima <[EMAIL PROTECTED]> in the NordSec conference (if my memory
serves me right) couple of years ago. Some of the attacks were really
quite embarrassing (for me, who designed the original SSH1 protocol :-)
The crc32 deattack code in ssh1 and openssh does not provide any
protection if you use stream ciphers. (There is some speculation that
it might even be possible to get around it when using block ciphers.)
There is no problem in using stream ciphers with SSH2, as it uses a
real, secure message authentication algorithm (HMAC-MD5 or HMAC-SHA1
typically).
Tatu
--
SSH Communications Security http://www.ssh.com/
SSH IPSEC Toolkit http://www.ipsec.com/
SSH Secure Shell http://www.ssh.com/ssh
