Originally posted by UncleVanya Key management is tricky and getting enough entropy in your seed method is as well. But assuming they use simple touchscreen password, then you have to wonder about performance. Raw files are huge and in line encryption will slow things down.
To do encryption correctly in camera would require using public key encryption as well as private key encryption. It would carry some additional overhead in processing time but that would mostly add to the latency not overall throughput. The way to correctly do this would be:
Hardware and Software requirements:
1. A dedicated IC for doing RSA and AES encryption as well as XOR with 2 streams
2. Additional memory for an encryption buffer
3. The RSA encryption should support 1024, 2048, 4096, and 8192 bit public key files
4. The AES encryption should support 128, 192, and 256 bit keys
5. The AES encryption is done in counter mode
6. A hardware random number generator (easy to do with a couple reverse biases transistors and support circuitry), or use some other in camera entropy sources like sensor noise, low order GPS timings, etc. as we only need a small bit of entropy for each picture (256 bits max)
7. The ability to turn on encrypting photos.
Once all that is in place a workable solution would be:
1. The camera owner creates a public key file and a private key file on their computer with the appropriate RSA key length.
2. The public key file is loaded onto the memory card for the camera (never put the private key file here) in the root directory
3. The camera is turned on
4. The camera reads the public key file
5. The camera generates a new AES key of the selected length from the entropy source
6. The camera fills the encryption buffer with encrypted 128 bit blocks that were encrypted with the AES key from step 5.
7. The camera encrypts the current AES key using the RSA public key
8. At this point the camera user maybe has finished reaching for the lens cap or if they have pressed the shutter has finally released the button
9. A picture is taken and processed normally
10. The picture data is XORed with the encryption buffer
11. The AES key size, encrypted AES key, and encrypted image are all written to a file
12. Until the camera is turned off or encrypting images is turned off go to step 5
To decrypt an image simply use the RSA private key to get the AES key and generate the necessary blocks and XOR them with the encrypted image data on your computer.
While this does add a number of additional steps most of them can be done in parallel so that they are waiting to be used as they are computationally easy. XOR is an extremely fast and simple thing to implement in hardware so even though it can't be done in parallel it won't affect performance. The most computationally expensive things would be generating the encrypted blocks but this can begin once the previous picture has been written. The next most computationally expensive thing would be encrypting the AES key with the public RSA key but that level of computation can be done with low power RFID tags so nothing to be concerned with.
That said at that point you still have encrypted data sitting on your camera which in terrible countries would get you rubber hosed anyway. So a better solution would be to tether your camera to something that can transmit over a secure communications path to a remote location. So if you are in some hell hole like North Korea you would have a sat phone and through either TOR, some VPN, or even a SSH tunnel just transfer the images securely to some safe remote host.
I also do agree with DeadJohn and that if going to such a questionable country one would likely be better served by using just a regular smart phone as they are more inconspicuous and there are programs out there to encrypt arbitrary files like OpenKeychain for android. Here one should hide the encrypted images in plain sight. encrypt them name the file somerandomething.bin and stick it in some other program's data directory. Upon cursory search it won't turn up anything suspicious, especially if you have some run of the mill photos of neat touristy things. I would still see about transmitting anything damaging off of the phone over a secure channel (TOR, VPN, SSH tunnel) as soon as possible but then transmitting multiple GB of data a day might draw other attention so maybe look into just physically smuggling out some microSD cards with the important data.