I'm thinking about ways to encrypt an endless stream of data (e.g. a video or audio feed) in a way, where a compromise of the current internal state of the encryption (e.g. a RAM dump) does not comprimse data encrypted earlier without knowing the seeding parameters (Key, IV). A stream cipher would be preferrable to a block cipher, because this way one could guarantee that there are no incomplete blocks of data waiting for encryption.

Exemplary non-solutions:

  • Generating a pseudo-random one-time-pad-like key stream and saving this encrypted asymetrically might solve the problem, but does not seem to be very efficient; more practically one might pre-generate key blocks using a stream cipher, and only encrypting the IVs. I'd expect that there might be a known solution using symmetric ciphers (e.g. AES) too, but I can't seem to find one.

  • Common cipher modes do not seem to be suitable, since all of them use a constant key for the AES encryption, which allows to revert all encryption already done.

  • I reckon that this cannot work well with a constant key -- only discarding the IV from memory would not prevent reconstructing it; replacing a counter mode counter with a non-revertable hash chain would be susceptible to partial-known-plaintext-attacks (e.g. predictable video headers) and using an PRNG instead of a counter would only relocate this problem to finding a suitable PRNG that is not susceptible to a leaked internal state (e.g. by still having its seed in RAM).

  • Some similar ideas have been documented by https://bitslog.com/2013/02/22/block-ciphers-modes-with-forward-secrecy-for-cryptocatotr/ for the OTR protocol.

Is there a trivial reason why the common block cipher modes appear to only vary the plain text input of the block cipher, but never the key?

Is there maybe a well-known block cipher mode providing such a stream cipher that I failed to identify as such?

  • $\begingroup$ Did you see how Netflix does? $\endgroup$ – kelalaka Oct 2 '19 at 19:06
  • $\begingroup$ I did not -- however, GCM does not seem suitable for this use-case, since I'd still need the constant block cipher key to encrypt the data in the feature, which -- given some known plaintext -- is sufficient to reconstruct the IV, the counters and thus to decrypt all ciphertext generated in the past following (edit: and even preceding) this single block of known plaintext. $\endgroup$ – phi1010 Oct 2 '19 at 19:13
  • $\begingroup$ The point is, you want more than NetFlix. Once the data in my computer I can do, all. $\endgroup$ – kelalaka Oct 2 '19 at 19:17
  • $\begingroup$ I cannot see where Netflix did write about forward secrecy -- both the answer, the referenced article and both papers by Stewart et al. focus on performance for authentication considering GMAC vs HMAC -- authentication however is not part of my goal here. $\endgroup$ – phi1010 Oct 2 '19 at 19:22
  • 3
    $\begingroup$ If both parties agree on exactly how and when to do this, you can use part of the output of the stream cipher to replace the key and keep going. Then knowledge of the current key won't enable decryption of anything encrypted with the previous key, so all you need to do is erase the previous key. See blog.cr.yp.to/20170723-random.html for an example. No need for public-key cryptography; ‘forward secrecy’ is just a confusing word to obscure when a protocol can erase past keys (and worse when qualified by the loaded word ‘perfect’ which adds no technical content to the term). $\endgroup$ – Squeamish Ossifrage Oct 2 '19 at 20:49

Your Answer

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

Browse other questions tagged or ask your own question.