3 ms·

You don't need any buffering if you pick your encryption mode correctly. That is, use a stream cipher.

• mikepurvis 6y ago
  How much would that affect the ability to recover a partially-corrupted stream, though? I feel like that's part of this too— where the last few seconds might have an increasing amount of the content scrambled, and encryption would render that completely unusable, whereas having it in plaintext would still permit some degree of inference about the fragments you do have.
  • vardump 6y ago
    It would not affect at all. Flipped bits / transmit errors have no avalanche effect, unless the bit was flipped in the encryption module.
    • mikepurvis 6y ago
      What if you have gaps in your stream with uncertain length, though? Based on quick read about stream ciphers, it seems like the alignment of the key and data is pretty critical.
      • vardump 6y ago
        Might be some truth here. Although at this point automatically interpreting plain text data would fail as well. In both cases, you could add separating symbols in the raw data stream. Also, timing should help here. Sure there can be gaps, but at a given data rate the receiving end should be able to compensate for it, as long as velocity doesn't have large unexpected changes (doppler). Even then it should be decodable afterwards. There are a lot of ways you can compensate for any of these issues. That said, of course plain text is going to be the easiest option for a human to decode when everything else fails.