Efficient hardware implementation of real-time asymmetric video encryption I want to encrypt video directly at the source where it is being captured, e.g. inside a video camera. This way I can transmit the encrypted stream over WiFi securely.

I could use AES on the chip inside the camera, but this would be open to an attack on the semiconductor package, where an actor could retrieve the AES encryption key and use it to decrypt the data.

Is there an asymmetric encryption algorithm like RSA (which is unfortunately not efficient to encrypt a video stream), that is efficient at encrypting a video stream and that can also be implemented in hardware (like on an ASIC chip)?

This would allow me to store only the public key inside the ASIC, thereby increasing security. After receiving the encrypted stream I would be able to use the private key to decrypt it.

Would you recommend the video stream being compressed before being encrypted?
Would you recommend the video stream being compressed before being
  encrypted?


This is an excellent question in itself. What compression does, it recognizes redundancies in the data and removes those. So it changes the length of the data as a function of its value. Now cryptography doesn't promise to hide the length of the transmitted data, because that would be an impossible goal to achieve. So an outside attacker, could now go ahead and deduce some information about the plaintext, through the encryption, simply by looking at the length and frequency of packet transmissions. This in fact has been a famous attack, called CRIME, and has lead to TLS abandoning compression at the security protocol level. So you have to evaluate yourself whether the trade-off of leakage versus size gains is worth it to you.

Of course, with video being nicely encode-able with lossy methods, you can get a constant bit-rate encoding, where each unit of time of video material is encoded to the same unit of bit-output. As indicated in the other answers and the comments, this should leak very little to no information.



Now for your actual question:
(Hybrid) McEliece

McEliece is an old code-based signature scheme. It encrypts data by running it (as a vector) through a matrix-vector multiplication and then adds a limited amount of noise to the result. The decryption is more involved and essentially works off of error correction codes being applied to remove these errors. So let's go through things to figure out why it would be a good pick:


It is insanely fast. As you read above, it's simply a binary matrix-vector multiplication and a binary vector addition with some carefully generated noise. As such it is essentially, naturally, a lagre bunch of AND and XOR gates along with the output of a HW RNG, which can be built to be quite fast somewhat easily.
It is post-quantum resistant. McEliece (well, variants of it) are currently considered for the NIST post-quantum competition and McEliece has stood the test of time against quantum algorithms for a few decades now.
It has a large public key. Given that you don't actually seem to want to transmit the public key, this shouldn't be a problem in your case and even then, you mostly transmit video data, an extra Megabyte for the public key won't end the world.
Decryption is somewhat complicated. But this doesn't seem to be much of an issue for you, as far as I can tell.
It is rather badly supported. That is, it is used very sparsely. Given that you roll your own ASIC, you seem to be able to set your own standard here, but make sure to run things through proper cryptographers and don't just take the word of a random internet potato!
It lacks a lot of standardisation. When you use it "raw", that is not for some hybrid encryption as would be usual these days, you need to look around a bit to find a padding scheme that makes McEliece IND-CCA2 secure, which is really a security notion you want, but again, consult a proper cryptographer on this!


Now for your actual problem: The slow speed of asymmetric cryptogaphy. Well, there the solution of hybrid encryption. That is you take your favourite encryption scheme (such as McEliece), encrypt a lot of random bytes with it, prepend the ciphertext to the message and use the hash of the bytes as the key for authenticated symmetric encryption. This has the advantage that you can now keep the key for a (short) period of time in volatile registers and use the fast symmetric crypto to do the bulk of the work. Of course you can also pair hybrid encryption with slow asymmetric crypto such as RSA and just continuesly run the RSA encryption in a loop, generating a new session key once a second or so. The advantage of the hybrid encryption is that you need to spend less area on the asymmetric crypto (because you need less parallel instances / less area-time-trade-offs) and more on your actual logic and of course the fact, that you should have no problem finding pre-made IP for such symmetric encryption modules.