Login | Register   
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

RC4 Usage Errors Leave Your Data Exposed

Some inherent usage errors in many applications that employ the RC4 algorithm leave the applications vulnerable to attacks. Learn these errors and how to rectify them.


advertisement
recently read an advertisement for some Windows security software that boasted "incredible security using 160-bit RC4." Superlatives aside, take claims like this with a grain of salt. Based on the products I've looked at, many applications using the RC4 algorithm for encryption are vulnerable to attacks because of two issues:
  1. RC4 produces the same key stream for each unique key a user or application provides.
  2. RC4 encrypts data one byte at a time.
RC4 itself is not a cryptographically weak algorithm, but some inherent usage errors in many applications that employ RC4 leave the applications vulnerable to attacks. I will discuss these errors and how to rectify them. But before discussing its problems, let's briefly look at how RC4 works.

How RC4 Works
RC4 is a stream cipher (another example is A5, which is used in GSM cell phones), which means that data usually is encrypted and decrypted one byte at a time. Other ciphers, such as RC2, 3DES, DES, and AES, encrypt and decrypt data in blocks, often 64-bit or 128-bit blocks. RC4 is the default stream cipher included with Crypto API in Windows.

RC4 works like this:

  • The user or application provides a key.
  • RC4 uses the key to create a stream of random bytes, which are XORed (the mathematical symbol for XOR is ) with the plaintext to yield the ciphertext or XORed with the ciphertext to yield plaintext.
It's a very simple and fast process indeed.



The Problem
Each unique key derives the same RC4 key stream, and herein lies the problem. If the key is re-used and an attacker gains access to the one ciphertext, he/she can XOR the ciphertext and the plaintext to derive the key stream (provided this attacker knows the plaintext to that ciphertext). From that point on, the attacker can derive any plaintext encrypted with that key.

Actually, the attacker cannot derive all the plaintext of the second message; he/she can derive up to the same number of bytes that he/she knows in the first message. In other words, if you know the first 23 bytes from one message you can derive the first 23 bytes in the second message using this attack method.

If you're still unsure why this problem exists, remember the following rule regarding XORing data:

P K P = K

Where P is a byte of plaintext and K is a byte from the key stream.

A common scenario in which this issue comes up is when two computers communicate using RC4—A with B and B with A—and the data between them uses the same key. In fact, this was one of the issues that led to the Microsoft PPTP fix in 1998. As an example of breaking this chain, SSL/TLS also uses RC4 but does so in a more secure manner. The client and server communicate using RC4 but they do so using two different keys. The client uses one key to encrypt data sent to the server, while the server uses another key to send data to the client.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap