I have a situation where a slow Windows machine needs to make periodic automated connections to another machine via SSH. The performance of SSH on this slow machine is so bad it's actually become a bit of a problem. I've already suggested replacing the problem machine with faster one, but have been shot down.

I'm considering trying the arcfour -aka RC4 -cipher with SSH on the slow machine. I've read that it's less secure but faster than AES or blowfish. So what exactly would be at risk? My understanding is there's 3 things SSH offers security on:

  1. The privacy of the data communicated via SSH
  2. Assurance of the server that the client is who he/she claims to be. That is, valid username + password/SSH key combination.
  3. Asurrance to the client that the server machine is who it claims to be, via the keys in the server's /etc directory.

For my specific case, we can live with pretty low security for #1, #2 is troubling but not a deal breaker. For this particular slow machine, #3 is also acceptable. But I am concerned about #3 being somehow impacted for other clients.

The account being connected to on the server is unprivileged and already locked down pretty well, so anyone connecting as that user shouldn't be able to do something obvious like alter critical files on the server. But could an attacker do something like gain some kind of insight into the server keys if he/she can crack transactions made with the weaker RC4 sessions? Which of the afore-mentioned three aspects does using a weaker cipher put at risk?

P.S.: SSH's connection sharing feature would probably be the best answer, but unfortunately doesn't seem to be supported on Windows. Also, using the blowfish cipher instead of AES did offer some improvement but it's still pretty bad.

  • 1
    the change to rc4 mainly impacts item 1. – tony roth Aug 15 '13 at 14:28
  • The difference in computation speed between the two algorithms is so small... there must be other ways to more effectively save CPU cycles. I think you're not seeing the forest for the trees here. Have you considered 1) Upgrading to a newer version of Windows, 2) Uninstalling unnecessary software, 2) Turning off unnecessary services, 3) Not using Windows? (Note about #3 - I am actually pro Windows, but when I see you talking about SSH on Windows it's usually because you're doing something that was designed for a Nix OS.) – Ryan Ries Aug 15 '13 at 14:55

SSH will validate the server based on the signature of the public key used (a simple hash). It's up to the user to make sure that signature is valid (i.e. you usually need a secure channel for that also, in practice, clients usually just remember the first signature sent by the server and simply warn you if that signature changed).

This means that validating the server (correctly or incorrectly) isn't going to be influenced by your selection of symmetrical encryption algorythm.

That being said, I can more or less guarantee you that changing the symmetrical encryption from AES to RC4 isn't going to yield any noticeable performance improvement: even with a very slow (or starved) processor, the difference in speed between the two isn't going to be noticeable.

if you need more information, someone actually performed a detailed analysis if the performaces of AES vs RC4 (including several mode of operation for AES)

  • +1 for your 3rd paragraph. I think OP is chasing a red herring here. – Ryan Ries Aug 15 '13 at 14:57

I'm no expert on this but (assuming that the problem is with the ciphers) using RC4 doesn't help with authenticating the server - RC4 is used as the symmetric encryption algorithm and not the asymmetric connection set up phase (where IIRC identity is determined). Maybe a PSK based method would be a more appropraite method to avoid performance problems due to computation overhead?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.