RFC 4345

RFC 4345 🎀 Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer Protocol

okay bestie, title block first so we know the vibes 🧚. It's RFC 4345, written by B. Harris (Ben Harris 🇬🇧), dated January 2006. The category is Standards Track 👑, which means it's an actual Internet standard and not just an idea. The original title block doesn't list anything it obsoletes or updates, so there's nothing to chase down there 🤷‍♀️.

Status of This Memo ✨

This is an Internet standards track protocol doc for the whole Internet community, and it's basically asking for discussion and suggestions 💬. If you want to know where it stands in the official standardization pipeline, check the current edition of "Internet Official Protocol Standards" (STD 1) 📚. And distribution is unlimited, so share away 🦋.

Copyright Notice 🌸

Copyright (C) The Internet Society (2006).

Abstract 💜

This doc explains how to use the Arcfour cipher inside SSH in a way that patches up the weakness in its key-scheduling algorithm 🩹. Arcfour is the one we're talking about here, and it's also known as RC4 🔐.

1. Introduction 🦋

Okay so SSH [RFC4251] is a secure remote-login protocol 🖥️. It can use a whole bunch of different symmetric cipher algorithms to keep data private while it's moving around ✨. One of the ones in the base protocol is "arcfour", which is Arcfour (aka RC4), a fast stream cipher 🏎️.

Here's the tea: [RFC4253] itself says, "Arcfour (and RC4) has problems with weak keys, and should be used with caution." 🙈 [MANTIN01] goes deeper into those problems and recommends tossing the first 1536 bytes of keystream so the cipher's internal state gets properly mixed up 🌀. This document adds new SSH cipher algorithms that follow that advice 💅.

2. Conventions Used in this Document 📏

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 🎀.

3. Applicability Statement 🍓

Arcfour implementations are usually a bit faster and way smaller than any other encryption algorithm currently defined for SSH 🏃‍♀️. That speed comes with a catch though, because of the known security problems with Arcfour that we cover in Section 5 😬. When speed and code size aren't the critical issues, the algorithms from [RFC4344] should be used instead 💖.

4. Algorithm Definitions 🧚

The "arcfour128" algorithm is RC4 as described in [SCHNEIER], using a 128-bit key 🔑. The first 1536 bytes of keystream generated by the cipher MUST be discarded 🗑️, and the first byte of the first encrypted packet MUST be encrypted using the 1537th byte of keystream ✨.

The "arcfour256" algorithm is the same thing, just with a 256-bit key 🌈.

5. Security Considerations 🔥

Yep, the security considerations in [RFC4251] apply here too 🛡️.

This part is serious, bestie 😭. The discarded bytes of keystream MUST be kept secret, and they MUST NOT be sent over the network 🤫. Their contents could reveal information about the key, and that would be a disaster 💀.

⚠️ Arcfour has two classes of attack described in [MIRONOV], so pay attention. Strong distinguishers can tell an Arcfour keystream apart from random data at the start of the stream, and this document's algorithm is designed to defend against that 🛡️. Weak distinguishers can work on any part of the keystream, and the best ones, described in [FMcG] and [MANTIN05], can use data from multiple different keystreams 😱.

Here's the scary part. If you encrypt the same data over and over (say, a password) in separate Arcfour keystreams, enough repetitions can leak information about it to an attacker 👀. So it is RECOMMENDED that Arcfour (either in the form described here or the form described in [RFC4251]) not be used for high-volume password-authenticated connections 🙅‍♀️.

6. IANA Considerations 📋

IANA has assigned the Encryption Algorithm Names "arcfour128" and "arcfour256" in accordance with [RFC4250] 🎉.

7. References 📚

7.1. Normative References 💎

• [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
• [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Assigned Numbers", RFC 4250, January 2006.
• [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006.
• [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006.
• [RFC4344] Bellare, M., Kohno, T., and C. Namprempre, "The Secure Shell (SSH) Transport Layer Encryption Modes", RFC 4344, January 2006.
• [SCHNEIER] Schneier, B., "Applied Cryptography Second Edition: protocols algorithms and source in code in C", John Wiley and Sons, New York, NY, 1996.

7.2. Informative References 🌷

• [FMcG] Fluhrer, S. and D. McGrew, "Statistical Analysis of the Alleged RC4 Keystream Generator", Fast Software Encryption: 7th International Workshop, FSE 2000, April 2000, http://www.mindspring.com/~dmcgrew/rc4-03.pdf.
• [MANTIN01] Mantin, I., "Analysis of the Stream Cipher RC4", M.Sc. Thesis, Weizmann Institute of Science, 2001, http://www.wisdom.weizmann.ac.il/~itsik/RC4/Papers/Mantin1.zip.
• [MIRONOV] Mironov, I., "(Not So) Random Shuffles of RC4", Advances in Cryptology -- CRYPTO 2002: 22nd Annual International Cryptology Conference, August 2002, http://eprint.iacr.org/2002/067.pdf.
• [MANTIN05] Mantin, I., "Predicting and Distinguishing Attacks on RC4 Keystream Generator", Advances in Cryptology -- EUROCRYPT 2005: 24th Annual International Conference on the Theory and Applications of Cryptographic Techniques, May 2005.

Author's Address 💌

Ben Harris 2a Eachard Road CAMBRIDGE CB3 0HY UNITED KINGDOM

EMail: bjh21@bjh21.me.uk

Trademark Notice 🏷️

"RC4" and "SSH" are registered trademarks in the United States ™️.

Full Copyright Statement 🌈

Copyright (C) The Internet Society (2006).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights 💜.

This document and the information in it are provided on an "AS IS" basis, and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE 🫶.

Intellectual Property ⚖️

The IETF doesn't take a position on whether any Intellectual Property Rights or other rights that someone might claim over the technology in this document are valid or how far they reach. It also doesn't say whether licenses for those rights are available, and it hasn't independently gone looking for such rights 🔍. You can find the procedures for rights in RFC documents in BCP 78 and BCP 79 📖.

Copies of IPR disclosures sent to the IETF Secretariat, any assurances of licenses that will be made available, and the results of any attempt to get a general license or permission for implementers or users are available from the IETF's online IPR repository at http://www.ietf.org/ipr 🗂️.

The IETF invites anyone interested to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that information to the IETF at ietf-ipr@ietf.org 📬.

Acknowledgement 🙏

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA) 💖.