Is it possible using RC4 that for e.g. a 17-bit long plaintext i can get a 17-bit long ciphertext?

From my understanding, for this example i need a 17-bit long key to do the XOR operation for encryption. However in the normal algorithm of the RC4 only keylengths of 1 to 256 bytes are permitted.

Can i use 3 bytes = 24 bits as keylength and discard 7 bits in the generation of the random bytes K which i use for encryption?

Or is there another workaround which i am missing?

  • $\begingroup$ BTW, you should also take in consideration that 17 bit encryption is not that big in terms of security. $\endgroup$ – Yury Schkatula May 29 '18 at 17:05
  • $\begingroup$ May I suggest that you use a modern stream cipher like ChaCha instead of the broken archaic garbage that is RC4? $\endgroup$ – Squeamish Ossifrage May 29 '18 at 20:31
  • $\begingroup$ @YurySchkatula i know but it is only an arbitrary chosen number for understanding purposes $\endgroup$ – Don May 29 '18 at 21:01

This is about a misunderstanding. RC4 is a stream cipher. That means that it takes an (input) key and generates a key stream. The bits of this key stream are then XOR'ed with the plaintext. The size of the key stream is not dependent on the size of the (input) key. The input key is not XOR'ed with the plaintext.

Generally RC4 implementations only handle bytes. That's OK, you can just give any input key you want between 40–2048 bits in steps of 8 bits.

Then you can encrypt with the resulting key stream, which means the XOR'ing with the key stream. You can just use 3 bytes / 24 bits of plaintext: say one byte with the least significant bit set (the other bits can have any value) followed by two bytes with the rest of the 16 bits. Then you encrypt those bytes.

Finally you retrieve back the 17 bits at the same position. Now you've encrypted 17 bits; the other 7 bits can be ignored or removed. When XOR'ing the bits of each byte are fully independent of each other, so the other bits are not needed.

Decryption is identical, so you can just ignore the same 7 bits again.

As indicated by others, RC4 is not considered secure. There are plenty of stream ciphers to choose from that are secure. You could also use AES in counter mode, although AES-CTR obviously does have specific input key sizes; the key stream will however work as expected.


Yes, RC4 can give 17-bit ciphertext for 17-bit plaintext. Nothing special is necessary beyond supporting bit-sized plaintext and ciphertext.

In RC4:

  • The ciphertext has precisely the size of the plaintext, and that can be with bit granularity. It is simply the plaintext XORed with the keystream produced by RC4 from the key.
  • Key size is 1 to 256 bytes, fully independent of that of plaintext and ciphertext.

If one must use RC4 despite its known weaknesses:

  • Key should have ample entropy, like 16 bytes uniformly random bytes.
  • If the key is used more than once, a fixed-size Initialization Vector (number used once or at least 10 uniformly random bytes) should appended (or prepended) to the actual key.
  • The first few hundred bytes (say 2048) of keystream should be discarded.
  • An independent mean should provide integrity when needed (that is, in most applications).

And as noted in comment, thats not enough to lake RC4 secure.

  • 2
    $\begingroup$ Beware that RC4 is badly broken and has been since days after its publication in 1994, and it's still broken even if you discard the first 2048 bytes. Just Say No to RC4! $\endgroup$ – Squeamish Ossifrage May 29 '18 at 18:39
  • 1
    $\begingroup$ I don't think RC4 can be construed even to have lake security. $\endgroup$ – Squeamish Ossifrage May 29 '18 at 18:59

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.