For the pretty limited usecase of a "record only" dashcam, you might consider recording in chunks.
Create an ephemeral key for a symmetric encryption in advance, encrypt this ephemeral key with the public-key method of your choice and store somewhere. Then encrypt one minute of recording using this ephemeral key. I don't know if gnupg is performing good enough on all architectures, but in principle it can handle everything in one go, and it works exactly as described just above.
~ dd if=/dev/zero bs=1M count=50 | gpg -e -r 0x6AC3E4EC >encrypted.dat
50+0 records in
50+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 0.486881 s, 108 MB/s
(Intel(R) Core(TM) i5 CPU M 450 @ 2.40GHz)
If you use mpeg transport streams, you can even cut at arbitrary positions (to make, say, each file exactly 50 MiB large). When you play back, decoders will catch up as soon as they find the proper markers. So your encryption pipeline doesn't even have to know much about video...
Just pondered... there might be everything already be installed in a typical linux system, "split" does the right thing and can pipe into a command. Probably not the most efficient (making several copies of the data), but certainly enough for a proof-of-concept.
$ dd if=/dev/urandom bs=1M | \
split -b5000000 -d -a4 --verbose \
--filter="gpg -e -r 0x6AC3E4EC >\$FILE" \
- recording_
executing with FILE=recording_0000
executing with FILE=recording_0001
executing with FILE=recording_0002
(...)
• -b500000 split at 50 megabyte input file size.
• -d decimal suffixes (0001, ... else aa..az..zz)
• -a4 : suffixes of length 4 (0000)
• --filter="" : filter through pgp, intended output file is in variable $FILE
• - : read stdin
• recording_ : prefix output files with this string
Create an ephemeral key for a symmetric encryption in advance, encrypt this ephemeral key with the public-key method of your choice and store somewhere. Then encrypt one minute of recording using this ephemeral key. I don't know if gnupg is performing good enough on all architectures, but in principle it can handle everything in one go, and it works exactly as described just above.
If you use mpeg transport streams, you can even cut at arbitrary positions (to make, say, each file exactly 50 MiB large). When you play back, decoders will catch up as soon as they find the proper markers. So your encryption pipeline doesn't even have to know much about video...