encrypted video stream? you mean to encrypt the stream itself?
raspbian has support and packages for everything you could do with openvpn on a normal debian system, so you can totally build a point to point openvpn tunnel for traffic if that will suit your needs.
if all you want to do is upload image files you can script it with ssh public/private key auth and something like rsync/sftp/scp
And indeed Debian (raspbian) has a ton of components that I can string together, but it doesn't appear entirely trivial to make a low-powered system encode (h264 is expensive by itself) and encrypt a video stream of a decent frame rate and resolution and upload it to a standard file host, all close to realtime (perhaps up to ~4 seconds delay, that should be fast enough even if the intruder knows about the cam (Kerckhoff's principle) and immediately moves to pull the plug).
I don't think it can be done with entirely off-the-shelf components actually, it probably requires quite a bit of glue to make the components work together, cleanup files (locally and remotely), etc., but I'd be happy to be told I'm wrong :)
Edit: did you edit this in?
> if all you want to do is upload image files
Well kinda, but multiple images per second and preferably with some delta algorithm so they're not 100k×86400×fps = something on the order of 50GiB/day. A h264-compressed stream is an order of magnitude smaller. (Sunrise is the worst, increases the stream size by ~3×.)
The CPU horsepower may be a limiting factor, but your best best for putting it together from common raspbian/debian software pieces would be using ffmpeg as an RTSP video stream server, and a separate way of encrypting the network traffic end to end (openvpn, wireguard, a more traditional ipsec tunnel, mounting a remote mount-point over sshfs and continually writing small temporary files to the destination, etc). Then at the destination end, have your choice of RTSP client/stream-receiving software pulling the video feed.
Some of the back end software pieces to do it are not very dissimilar from a typical 'zoneminder' install on amd64 debian. Yeah I edited that in after I forgot to include it before hitting the post button...
on something like a raspberry pi 3b+ or 4 you might get good results by using a video frame rate around 5fps. Or even if you went down to 2-3fps that would be functionally equivalent to a constant stream of still images, depending on what the stream is needed for. If it were a security camera that needs to see peoples' faces the frame rate could be too low, a moving person might pass through the frame without any good shots of their face.
If you have lots of network bandwidth you can do a great deal with ffmpeg by not transcoding the video from the format it's acquired from, which is very helpful on systems with limited CPU power.
ZoneMinder doesn't do encryption, not sure if it would allow adding in gpg as a plugin somewhere.
Network bandwidth is generally not metered on home connections, so that's indeed not an issue, but storage isn't infinite. Transcoding the video would be a plus and can't happen remotely due to encryption. Raw mjpeg is also an option though, storage isn't that expensive (or throw more CPU at the encoding system; a raspberry pi is just an example).
> encrypting the network traffic end to end
but the video stream? The idea is that the storage server (Google, for that matter) doesn't need access to my video stream. Not sure if end to end encryption is too much to ask but I did figure since it's 2020, it should be doable.
Thanks for your responses by the way, it's helpful to have a second pair of eyes on finding a simple solution. Since there doesn't appear to be one, I will start experimenting with some ideas, feeding ffmpeg to gpg and checking cpu vs. compression ratio etc. Next step will be seeing which protocol to use for local + remote writing of the encrypted file (not sure if sshfs does incremental writes / appends). Let's see how hard this is! :)
> Transcoding the video would be a plus and can't happen remotely due to encryption.
why couldn't it? Unless the remote system (where the video is being received) is untrustworthy. In my scenario I was describing network traffic encryption, for a theoretical where the entire network between the video-sending and video-receiving linux systems could be 'hostile', but not encryption of the video itself, I was assuming that the location where the video is being sent to is trustworthy.
If the video needs to go to a remote storage location where you want files to be written to disk, but nobody else to be able to read them, that's a somewhat more rare problem to solve. Possibly something involving a virtual machine with a dm-crypt/LUKS implementation for FDE.
> Unless the remote system (where the video is being received) is untrustworthy
Well, that's part of the threat model. There is no need to trust the remote end fully, especially since I'm hoping that I can host at Google / OVH / Hetzner / whatever. I trust them as a backup and not to collude with a burglar, but why give them plaintext data?
... To answer my own question, not adding encryption makes life easy I suppose... but that's not very satisfactory imo :)
raspbian has support and packages for everything you could do with openvpn on a normal debian system, so you can totally build a point to point openvpn tunnel for traffic if that will suit your needs.
if all you want to do is upload image files you can script it with ssh public/private key auth and something like rsync/sftp/scp