24

What are the differences between the arcfour, arcfour128 and arcfour256 ciphers in OpenSSH?

I am interested about: speed and security implications.

I know that arcfour is fast for file transfers, but I don't know which one to pick.

sorin
  • 365
  • 1
  • 3
  • 7
  • 1
    If you want fast file transfers over SSH, consider using http://www.psc.edu/index.php/hpn-ssh . – Matrix Jan 09 '13 at 14:41
  • @Matrix That patch only improves performance for high-latency but high-throughput networks (e.g. trans-oceanic) where both sides are using HPN. It can actually reduce performance in many cases. – forest Jan 07 '19 at 01:51

1 Answers1

28

The "arcfour" cipher is defined in RFC 4253; it is plain RC4 with a 128-bit key.

"arcfour128" and "arcfour256" are defined in RFC 4345. They use a key of 128-bit or 256-bit, respectively. Moreover, and contrary to plain "arcfour", they also include a "discard" step: the very first 1536 bytes produced by the cipher are dropped. This is done because the first bytes of RC4 output tend to exhibit biases, which are rarely fatal to your security, but worrisome nonetheless. "arcfour128" and "arcfour256" are thus "more secure" than plain "arcfour".

Note that the extended key size of arcfour256 does not buy you much: a 128-bit key is already more than enough to defeat key cracking through brute force. A 256-bit key is more for aesthetic than rational reasons (there is a widespread belief among auditors that bigger keys are always better, just like there is a widespread belief among people in general that bigger cars are always better).

Note also that while dropping the first 1536 bytes of output fixes issues with the biases in the first 1536 bytes (of course...), it does nothing against the other biases in RC4 output (RC4 output can be distinguished from randomness after about one gigabyte). There again, these biases have never proven fatal in any deployed protocol; however, they "look bad" in audit conditions.

As for performance, there shall be no difference whatsoever, since RC4 speed does not depend upon key size. The extra 1536 bytes implied by arcfour128 and arcfour256 theoretically induce a small one-time extra cost, but that's way below the millisecond worth of CPU even on an asthmatic embedded ARM or Mips, so this would be very hard to even detect in practice.

Summary: use arcfour128 when possible, fallback to arcfour. Use arcfour256 if you need to impress bureaucrats by spewing out huge numbers that they will not understand, but which will cow them into submission.

However, network is usually the bottleneck, so even over gigabit ethernet, AES-based ciphers should provide the same actual speed than RC4, and with arguably better security (even in the skewed view of auditors). If unsure, measure; don't believe one cipher to be faster than another because you read it as some old lore which was thought out at a time when a PentiumPro was the summit of Earth-based technology.

Community
  • 1
Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • Modern CPUs have AES instructions, and with these a ciphersuite like AES-GCM should be *really* fast. – CodesInChaos Jan 09 '13 at 14:25
  • 2
    ...which is all the more a good reason to make measures on the actual hardware. – Thomas Pornin Jan 09 '13 at 14:27
  • what about all the recent attacks on RC4? – David 天宇 Wong Sep 20 '16 at 19:50
  • 4
    2016 - as most of CPUs nowadays supports AES instructions AES cipher is faster than arcfour and blowfish. I have a few old servers (~ 2010) where arcfour is still faster than AES. With hw EAS support enabled AES is ~50% faster than arcfour. Test speed with: for i in \`ssh -Q cipher\`; do dd if=/dev/zero bs=1M count=100 2> /dev/null | ssh -c $i localhost "(time -p cat) > /dev/null" 2>&1 | grep real | awk '{print "'$i': "100 / $2" MB/s" }'; done – oᴉɹǝɥɔ Jan 12 '17 at 19:46