Return to Stream Cipher (thing)

What is a stream cipher?

A stream cipher is a [symmetric encryption] method that usually operates at the [character] or [bit] level, with the [plaintext] being combined (normally by an [operation] such as [XOR]) with a generated [keystream] to produce the [ciphertext].

Although seemingly [simple], its [security] stems from the fact that, if the generated [keystream] [cryptographically secure random number sequence|is not distinguishable from a random sequence] and used only once to [encrypt] a [message], it has the same security as a [one time pad]. Particular [requirements] for a good stream cipher are a long [period] and high [linear complexity], but not all [ciphers] with these requirements are necessarily [secure].

They are often built using [counter|counters], [Linear Feedback Shift Register|linear feedback shift registers], [NLFSR|nonlinear feedback shift registers], [nonlinear] filters and/or [S-box|S-boxes], [cryptographic sponge|cryptographic sponges], [T-function|T-functions] or even more complicated things.

Regardless of their internal components, stream ciphers can be generally seen as [finite state machine|finite state machines]: they take some [input] ([internal state], [key] and optionally, as in the case of [self-synchronizing stream cipher|self-synchronizing stream ciphers] past [ciphertext]), perform some [operation|operations] and [output] the next internal state. A part (or even a [nonlinear] function of parts) of the internal state are also output at each step as the [keystream].

This implies that a stream cipher can never really attain the security level of a [one time pad], as [sequences] generated by a [finite state machine] are always [periodic] and, therefore, non-[random] (it might just have a [period] that exceeds the remaining time until [The heat death of the Universe|the heat death of the Universe], but it's still [finite]).

One very obvious "problem" with a stream cipher is that if you re-use a [key] (or a [key]+[Initialization Vector|IV] pair), the generated [keystream] will be the same, compromising the security of the [plaintexts] encrypted with such keystream (but, hey... [That's not a bug, that's a feature!|that's not a bug, it's a feature!] otherwise, the other party wouldn't be able to replicate the correct keystream and therefore decrypt your message).

Why not just use a [block cipher]?

A block cipher, unlike a stream cipher, operates at the level of blocks, providing a (key-dependent) [permutation] family which should resemble, as much as possible, a group of [pseudo-random] [permutation|permutations] ([pseudo-random permutation|PRP]). This implies that thorough [diffusion] ([mixing]) and [confusion] ([nonlinear] layers) are required for a certain level of [robustness] against [cryptanalysis].

On the other hand, a stream cipher usually only exposes part (or even a [nonlinear combination] of parts) of its [internal state] at each step, which implies that it can probably afford less [mixing] and [non-linearity|nonlinearity] than a full [block cipher] between each step (with [LFSR] being an extreme example, with very slow mixing of its internal state between each step). They are also often more efficient in [hardware] than block ciphers, being therefore a very valid choice for [symmetric encryption] in embedded systems and low-power requirements situations (e.g. [smartcards]).

Nonetheless, it is true that the design and [cryptanalysis|attack] of block ciphers is much better understood in [academia], which generally grants block ciphers a higher sense of security (due to heightened scrutiny regarding their designs). Also, it's [trivial] to build a secure stream cipher using a secure [block cipher] in [CTR|counter mode] and/or using a [block cipher] to mix some [internal state].

Examples of stream ciphers

  • [RC4]
  • [Trivium]
  • [MICKEY]
  • [HC-256]
  • [A5/1]
  • [A5/2]
  • [Panama]
  • [MUGI]
  • [Grain]
  • [Rabbit]
  • [Salsa20]
  • [SNOW]
  • [SOBER]
  • [VEST]
  • [AES] in [CTR|counter mode]