Software:CipherSaber

Short description: Encryption protocol

CipherSaber is a simple symmetric encryption protocol based on the RC4 stream cipher. Its goals are both technical and political: it gives reasonably strong protection of message confidentiality, yet it's designed to be simple enough that even novice programmers can memorize the algorithm and implement it from scratch. According to the designer, a CipherSaber version in the QBASIC programming language takes just sixteen lines of code. Its political aspect is that because it's so simple, it can be reimplemented anywhere at any time, and so it provides a way for users to communicate privately even if government or other controls make distribution of normal cryptographic software completely impossible.

History and purpose

CipherSaber was invented by Arnold Reinhold to keep strong cryptography in the hands of the public. Many governments have implemented legal restrictions on who can use cryptography, and many more have proposed them. By publicizing details on a secure yet easy-to-program encryption algorithm, Reinhold hopes to keep encryption technology accessible to everyone.

Unlike programs like PGP which are distributed as convenient-to-use prewritten software, Reinhold publishes CipherSaber only as a specification. The specification is intended to be so simple that even a beginning programmer can implement it easily. As the CipherSaber web site [1] explains:

In George Lucas's Star Wars trilogy, Jedi Knights were expected to make their own light sabers. The message was clear: a warrior confronted by a powerful empire bent on totalitarian control must be self-reliant. As we face a real threat of a ban on the distribution of strong cryptography, in the United States and possibly world-wide, we should emulate the Jedi masters by learning how to build strong cryptography programs all by ourselves. If this can be done, strong cryptography will become impossible to suppress.

The web site has a graphics file that displays as a "CipherKnight" certificate; however, that file is encrypted using CipherSaber with a known key published alongside the file. Users can view the graphic (and optionally print it out for framing) by first writing their own CipherSaber implementation to decrypt the file. By writing their own implementation and performing a few other small tasks, the user becomes a CipherKnight and the decrypted certificate attests to their knighthood. So, rather than providing a ready-made tool, CipherSaber's designer hopes to help computer users understand that they're capable of making their own strong cryptography programs without having to rely on professional developers or the permission of the government.

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.

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.

The ciphertext output is a binary byte stream that is designed to be "indistinguishable from random noise". 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.

Security and usability

CipherSaber is strong enough and usable enough to make its political point effectively. However, it falls markedly short of the security and convenience one would normally ask of such a cryptosystem. While CipherKnights can use CipherSaber to exchange occasional messages with each other reasonably securely, either for fun or in times of great distress, CipherSaber strips cryptography to its bare essentials and it does not offer enough features to be suitable for wide deployment and routine daily use. CipherSaber's author in fact asks users to download and install PGP as one of the steps of becoming a CipherKnight. CipherSaber can be seen as a last-resort fallback system to use if programs like PGP are banned. Some, but not all of CipherSaber's sacrifices and shortcomings are unique to RC4.

• CipherSaber provides no message authentication. This vulnerability, shared by all pure stream ciphers, is straightforward to exploit. For example, an attacker who knows that the message contains "Meet Jane and me tomorrow at 3:30 pm" at a particular point can recover the keystream at that point from the ciphertext and plaintext. Then the attacker can replace the original content with any other content of exactly the same length, such as "3:30 meeting is cancelled, stay home" by encrypting it with the recovered keystream, without knowing the encryption key.
• Like most ciphers in use for bulk data transfer today, CipherSaber is a symmetric-key cipher. Thus, each pair of communicating users must somehow securely agree on an encryption key, and each user must securely store the encryption keys of those they are to communicate with. Agreeing on encryption keys when the only communications channels available are insecure is the classic chicken-and-egg problem solved by public key cryptography as provided by PGP-like programs. Avoiding the need for secure symmetric key agreements between every pair of users is of considerable convenience and generally improves security. A protocol typically used to achieve good efficiency and convenience is to use a public key cipher such as RSA for key exchange, then a symmetric-key cipher such as CipherSaber for bulk data transfer using the negotiated key.
• The short key-setup RC4 used in CipherSaber-1 is broken: RC4's original key scheduling is now known to be too weak to protect a large number of ciphertexts encrypted using the same key. CipherSaber-2 modifies CipherSaber-1's key setup procedure by repeating it multiple times in the hope of improving its security (the result is equivalent to using conventional RC4 starting with a key that's been preprocessed by a complex algorithm). While this procedure is believed to close the RC4 key scheduling vulnerability, its effectiveness has not been proven.
• Like any chosen-key cipher, both versions of CipherSaber are vulnerable to dictionary attack if the chosen key (which would normally be a password or passphrase) does not have sufficient entropy. Symmetric-key cryptography implementations usually include a facility for generating random keys when high security is required. The CipherSaber site recommends generating high entropy random passphrases using Diceware.
• Like most other cryptosystems (including PGP), CipherSaber makes no provisions at all to prevent attackers from detecting (as opposed to decrypting) the encrypted messages. This is a potentially serious problem in some situations for which CipherSaber was designed: if the government has banned the distribution of cryptographic software, it probably also will want to pounce on anyone who it finds sending encrypted messages. See traffic analysis and steganography for more about these issues and their countermeasures.

Further reading

• Levine, John R., ed (2000). Internet Secrets (2 ed.). IDG Books. ISBN 0-7645-3239-1.