Editing CipherSaber (section)

== Technical description ==

In the original version of CipherSaber (now called CipherSaber-1 or CS1), each encrypted message begins with a random ten-[[byte]] [[initialization vector]] (IV). This IV is appended to the CipherSaber key to form the input to the RC4 key setup algorithm. The message, XORed with the RC4 [[keystream]], immediately follows.<ref>{{Cite web |last=Gary C. Kessler, Ph.D., CCE, CISSP |title=An Overview of Cryptography |url=https://www.garykessler.net/library/crypto.html |access-date=2025-04-24 |website=www.garykessler.net}}</ref>

The [[Fluhrer, Mantin and Shamir attack]] on RC4 has rendered CipherSaber-1 vulnerable if a large number (>1000) messages are sent with the same CipherSaber key.  To address this, the CipherSaber designer has made a modified protocol (called CipherSaber-2) in which the RC4 key setup loop is repeated multiple times (20 is recommended).  In addition to agreeing on a secret key, parties communicating with CipherSaber-2 must agree on how many times to repeat this loop.<ref>{{Cite web |title=CipherSaber FAQ |url=https://ciphersaber.gurus.org/faq.html |access-date=2025-04-24 |website=ciphersaber.gurus.org}}</ref>

The ciphertext output is a binary byte stream that is designed to be "indistinguishable from random noise".<ref>Arnold Reinhold, [http://ciphersaber.gurus.org CipherSaber home page]</ref>  For use with communications systems that can accept only [[ASCII]] data, the author recommends encoding the byte stream as hexadecimal digits.  This is less efficient than, for example, [[base64]] [[MIME]] encoding, but it is much simpler to program, keeping with CipherSaber's goal of maximal ease of implementation.