6

In a stream cipher like RC4, a message is xored with a random stream of bits, hence a n bits message will result in a n bits random-like ciphertext.

So it's a bijection, it's invertible, the output looks like a random element in {0,1}^n...

Why are stream ciphers not considered as PRPs?

anselant
  • 85
  • 5

4 Answers4

6

I assume that for a fixed key $K$, you are asking why $f(m) \overset{\underset{\mathrm{def}}{}}{=} <STREAM> \oplus\ m $ is not a PRP, where $<STREAM>$ is the stream that is generated from the key $K$. $f$ verifies at least two properties that PRP in general do not verify:

  • $f(m_1) \oplus f(m_2) = m_1 \oplus m_2$
  • $f(f(m_1)) = m_1$
Thomas Prest
  • 1,100
  • 8
  • 14
2

It sounds to me like this really comes down to definitions. If you look closely at how people use it, you may spot that the term "stream cipher" is regularly used in two closely related but distinct senses:

  1. A function $keystream : \exists M \!\in\! \mathbb{N}.\; (Key \times Nonce) \to \{0, 1\}^M$ that maps a (secret, randomly drawn) key and a (public) nonce to a long pseudorandom bit sequence of length $M$ (the cipher's maximum supported keystream length; e.g. $2^{70}$ for Salsa20);
  2. An encryption scheme that XORs messages of length $l$ with the $l$-bit prefix of such a keystream: $cipher : \exists M \!\in\! \mathbb{N}. \forall l \!\in\! \mathbb{N}.\; (l ≤ M \times Key \times Nonce \times \{0, 1\}^l) \to \{0, 1\}^l$.

You can spot these two senses, for example, in the specification of the Salsa20 stream cipher (section 10, boldface as in the original):

Let $k$ be a 32-byte or 16-byte sequence. Let $v$ be an 8-byte sequence. Let $m$ be an $l$-byte sequence for some $l \in \{0, 1, . . . , 2^{70}\}$. The Salsa20 encryption of $m$ with nonce $v$ under key $k$, denoted $Salsa20_k(v) ⊕ m$, is an $l$-byte sequence.

The function called $Salsa20_k(v)$ in this passage fits my type #1—it maps a key and nonce to a keystream (with the intent that if the key is drawn randomly and kept secret, the keystream is pseudorandom). That function is not a permutation. But the so-called "Salsa20 encryption of $m$ with nonce $v$ under key $k$," for any fixed $l ≤ 2^{70}$, $k$ and $v$, is indeed a permutation, and an involution as well.


EDIT: But Thomas Prest's answer points out that the fact that the permutation can't be a PRP, because if you picked a permutation at random it's unlikely you'd pick one that had the same properties we can observe of a one-time pad (the ideal counterpart to a stream cipher). More generally, there are $2^l$ possible messages of length $l$, which means that there are $2^l!$ possible permutations but only $2^l$ distinct one-time pads, so the chance that you'd pick a random permutation that's equivalent to some one-time pad is $1/2^{l-1}!$.

Luis Casillas
  • 14,703
  • 2
  • 33
  • 53
0

To make this tractable you need finite not infinite length output.

Finite length output would make the OTP with purely random key stream a random permutation of $\{0,1\}^n.$ For other additive keystream generators the proof has in general not been attempted as far as I know.

RC4 with its huge state would likely be a bad PRP, especially since significant biases are known in its keystream.

Finally, a block cipher used in a keystream mode of operation, e.g, CTR, could probably be analysed as a PRP, treating each encryption like a round in a block cipher, but I am not an expert in this area.

kodlu
  • 25,146
  • 2
  • 30
  • 63
0

It depends on the stream cipher, ChaCha and Salsa are actually iterated Even-Mansour ciphers with half the key known, so they are permutations.

RC4 is not a random permutation because each key does not produce a unique keystream.

There is a possibility that the key schedule may produce a collision. RC4 is also a reversible generator and has an average cycle length of 21699. It is possible for the start of one keystream to be in the middle of another keystream (but incredibly unlikely.).

user3201068
  • 721
  • 1
  • 5
  • 18