(With a stream cipher, a single bit error in the encrypted data results in a single bit error in the decrypted data).

Contrary to what other commenters suggest, a proper stream cipher like ChaCha20 is not even needed. You could just use CTR mode, which turns any block cipher (like AES) in a stream cipher and prevents ciphertext bit errors from creating more plaintext bit errors. Also, transmit the counter every once in a while so that dropped packets don't prevent you from decrypting subsequent packets.

[1] https://en.wikipedia.org/wiki/Viterbi_algorithm [2] https://en.wikipedia.org/wiki/Low-density_parity-check_code

Let's say you're using a 20/40 erasure encoding. You break a piece of data up into 20 pieces and create 20 extra parity pieces. Now you only need 20 out of the 40 to recreate the original data.

Are we encoding the encrypted data? Ok well we need at least 20 good pieces, and that's to decode the original data. This method doesn't allow for seamless degradation but allows for some data loss in the transmission (while effectively doubling the amount we're trying to push in the first place).

Let's say we're breaking up the original data, creating parity pieces and encrypting each little piece. Then it could decrypt each piece it got and use it and if it couldn't decrypt a piece just throw it away. This could potentially work but parity pieces are useless unless you are trying to recreate the original file neglecting the ability to degrade quality. So redundancy is more important in this scenario than parity.

But, if we make the encrypted pieces small enough, say each packet body, then that could probably work but be resource intensive. Encode/decode every packet, if successful insert into feed, else throw the packet away. This would work a lot like the existing technology just requiring some middle step of decrypting each packet body.

So in other words you can use what's basically the default mode of encryption, CBC. Each encrypted byte only depends on the adjacent 32 bytes, so you can allow errors through and they affect a couple pixels instead of a single pixel.

It seems if you lose any 32 bytes though you've lost the trail of encryption as you can't decrypt any subsequent pieces.

After reading other comments I think the only reliable solution is chacha20 where each packet can be encrypted/decrypted independently of others.

Let's assume CBC with AES. It encrypts in 16 byte blocks. If you slightly corrupt one block, you will fail to decrypt it entirely, and it will slightly corrupt the block after, but everything else will be fine.

There are modes of encryption where losing one bit will corrupt all subsequent bits.

There are also modes like GCM or stream ciphers like ChaCha20 where one corrupted bit will not corrupt any other bits at all.

In short: There are many options, and half of them are suitable for this.

You can take an analog signal and "quantize" it into sixteen possible values so that you can apply a parity algorithm that returns sensible results and doesn't fail with expected noise, but you're digitizing the signal.

Hopefully things have structured such that 802.11 packets are divisible by video frames.