-2
$\begingroup$

What make them better than OTP using a CSPRNG initialized with a secret key?

$\endgroup$
  • 1
    $\begingroup$ How is a CSPRNG different from a stream cipher? $\endgroup$ – CodesInChaos Nov 2 '15 at 16:10
  • $\begingroup$ A CSPRNG transform a key into a stream. A stream cipher transform a clear text stream into a cipher text stream. $\endgroup$ – daruma Nov 2 '15 at 16:26
  • $\begingroup$ And a stream cipher? $\endgroup$ – CodesInChaos Nov 2 '15 at 16:26
  • 1
    $\begingroup$ Many stream ciphers work by transforming a short key (and optionally a nonce) into a long key-stream that's xor-ed into the plaintext to produce the ciphertext, which is exactly the construction you're proposing. Wikipedia calls these Synchronous stream ciphers. $\endgroup$ – CodesInChaos Nov 2 '15 at 16:33
  • $\begingroup$ The API of a DRBG may be different in the sense that it may have methods to add seed information to the state. The stream produced may also have additional properties. That's however not of any consequence to the question posed. $\endgroup$ – Maarten Bodewes Nov 2 '15 at 20:46
10
$\begingroup$

Many stream ciphers work by transforming a short key (and optionally a nonce) into a long key-stream that's xor-ed into the plaintext to produce the ciphertext, which is exactly the construction you're proposing. Wikipedia calls these Synchronous stream ciphers.

Most popular stream ciphers fall into this category, including block ciphers operated in CTR or OFB mode, the venerable RC4 and e-stream finalists like Salsa20 or SOSEMANUK.

So a lot of research into stream ciphers doubles as research into CSPRNGs.

Some stream ciphers don't use this construction. For example:

  • CFB mode mixes the ciphertext into the cipher. This has the advantage that it "only" leaks the shared prefix and that it can re-synchronize after losing some data.

    In practice these advantages are rarely relevant, since you should use a nonce and MAC or a properly misuse resistant cipher. CFB mode is much less popular than CTR mode.

  • Helix/Phelix or the sponge based NORX also mix the message into the state of the cipher. The goal of these constructions is producing a cheap MAC, reusing the work the cipher has to do to produce the key-stream.

$\endgroup$
3
$\begingroup$

Using a CSPRNG to generate a pad is a stream cipher. However, that does not mean your question is without merit: if we could kill two birds with one stone by just designing CSPRNGs, that seems like a good idea. So why design dedicated stream ciphers?

One reason is performance. The performance we require from encryption is greater than what most uses require from a CSPRNG. That alone is not a very convincing reason, however, as we would prefer CSPRNGs to be fast as well.

The main reason, as I see it, is the differing requirements:

  • With a CSPRNG it is considered a useful property that the current state cannot be used to derive any earlier states. That means the CSPRNG must be run sequentially, so using it for encryption is also sequential. Parallelization would require multiple CSPRNGs running in parallel, meaning multiple seeds, more state, more complexity.
  • With stream ciphers the only requirements are that the output is indistinguishable from random and cannot be used to reveal the key. This allows constructions that are very easily parallelizable and potentially faster even when run sequentially.

Additionally, the other stream cipher constructions that CodesInChaos mentions differ from the random pad model, and have advantages like being able to reuse it for a MAC or some other cryptographic purpose that a CSPRNG might not be able to fulfill.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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