[Lord Lucan]

As a matter of interest :

Camera makers resist encryption, despite warnings from photographers | ZDNet

I notice that Pentax were not consulted.

[photoptimist]

Great! Now my own camera can block me from seeing my own pictures!!!!

This sounds like a feature that will only add misery to the life of the average photographer and not actually solve anything for photojournalists in dangerous areas.

[Kevin B123]

Encryption limits the usage of the camera due to this equation:
China + Encryption = Jail.
Other countries may turn that on to suit after you touch their soil too.
No thanks.

[Bob 256]

Use film.

[alfa75ts]

China + Encryption = Jail.

U.S. + Encryption May = Jail. Suspect jailed indefinitely for refusing to decrypt hard drives | ZDNet

[amoringello]

Jail may be a better alternative to death in those countries where confiscated photos show cause for such a sentence.
Destroying or making images unavailable may still result in jail time but may save a contact's life.
Photojournalists Ask Camera Brands for Encrypted Cameras

[Igor123]

As an option, why not? There seems to be A LOT of people that would like this, and different variants protect against different problems. Those who need it can use it, the rest don't need to care it's there...like jpeg and all the tons of features developed for it =)

There could be different levels for ease of use or different requirements in different scenarios:
1. Images transparently encrypted and viewable on camera, but actually encrypted when stored (with the camera knowing the password) so when the card is removed you need the key to view them elsewhere (so you don't need a computer to encrypt at home/hotel if worrying about thieves etc when leaving the card at home. Could be used during "safe" shooting conditions where the camera won't be taken from your hands, but you want encrypted storage)
2. Images encrypted by a password on camera, not viewable unless key is entered (valid in some border/search cases in different countries, or if worried about camera theft (same thing nowadays?))
3. Images encrypted by a public certificate uploaded by user, but you typically leave the private cert at home (protecting against the above xkcd-strip-scenario, since you actually can't decrypt until you get home, no matter how much they beat you)

But again..just a feature that could be enabled...so none of the "just adds problems"-arguments need bother..if it gets you in jail or is too complex, just don't use it.

I guess even if camera makers don't do this, it should be possible to add on the sd-card level like a flucard for number 2 and 3, but for encryption instead if wifi, while the camera just thinks it's a normal card (except for failing to view the images after shooting)

[UncleVanya]

Great! Now my own camera can block me from seeing my own pictures!!!!

This sounds like a feature that will only add misery to the life of the average photographer and not actually solve anything for photojournalists in dangerous areas.

THIS ^^^^^^

Encryption is already available. They can upload every frame to their phones and encrypt there or on a tablet or computer. The camera shouldn't be involved to avoid having to create backdoors or dumbed down models for counties like France and China than ban strong encryption.

[jpipg]

A little while ago, when looking at cameras produced by Ricoh, I discovered a Ricoh branded camera that offered encryption like this. It also offered hash bashed edit protection and was compatible with WORM write once SD cards. Not very useful to your average photographer but it doesn’t take much imagination to see a use case in industry and business such as insurance or police.

Interestingly Ricoh seems to be the only manufacturer that offered anything similar, maybe it will be added to Pentax cameras one day.

[Igor123]

THIS ^^^^^^

Encryption is already available. They can upload every frame to their phones and encrypt there or on a tablet or computer. The camera shouldn't be involved to avoid having to create backdoors or dumbed down models for counties like France and China than ban strong encryption.

I agree there could be consequences like additional development required, thus costing a bit more, and I don't need encryption myself (so I'd rather not pay for that work), but for me it wouldn't be different for than the camera having all the jpeg functionality and jpeg rendering at all from a conceptual point of view...I never use any of it, would prefer not to pay for it, but I see why others want it.

I mean, why do people want a screen or even controls at all on our cameras, why not let the phone handle it? Or GPS, or jpeg output or...you get my point it's a bit more convenient and better integrated if the camera has it build in =)

But I don't understand the other part of your comment...
- Current "computerlike" electronics (like cellphones) already support strong encryption in any country, even if not provided by the manufacturer it's very easy to add software that strongly encrypt files on any cellphone or computer..or do I misunderstand why special versions?

- As for backdoors, why would cameras have backdors but cellphones not have them? If anything, not being connected to google or apple constantly, and produced by japanase companies, if going by track record that would be less prone to government backdoors than american, chinese or russian compaines (but I don't have any illusion that they couldn't be forced by the government if need be..).

[UncleVanya]

If you take a laptop into a country that doesn't support strong encryption that is fine unless you use said encryption and you are caught. But importing the software that enables the encryption to a device sold in a country like that is typically illegal. Computers and phones can have software added it removed but aren't able to be sold with software that violates their encryption laws. Dedicated devices like cameras would need alternate versions of firmware to offer models that were legal to sell in those places. Obviously computers can more easily get around this with free encryption software readily available, prepackaged integrated devices are the ones impacted the most.

[Igor123]

Ok, I see how that could be a problem then (having to have 2 versions or more of the firmware would cost more and force 2nd hand buyers to watch out), but then it seems there already is a 2nd version with disabled gps for China?...but more versions and combinations of what they contain makes it more complex I agree, but as long as the firmware is replaceable I guess as a user I could live with that.

Maybe that's why makers stay away from it, but on the other hand, since there seem to be a demand perhaps the first one to have it would see some increased sales if marketing it properly =)...I doubt its very hard to implement, there are "uncrackable" algos publicly described and the processing required shouldn't be a lot more than say some postprocessing steps already used...but now I'm drifting off topic perhaps =)

[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.

[DeadJohn]

Computer security (including smartphones) is a big thing because we have bank accounts, tax records, medical data, business dealings, etc. We need to be vigilant for viruses and for stolen data. There's a huge market for overall computer security, with encryption being one part of that.

Camera security, though, is only a concern for a small fraction of photographers. The market seems limited to some photojournalists plus [illegal uses I won't delve into]. A journalist trying to covertly photograph something might be better with a smartphone rather than a more obvious camera, anyway, further reducing the potential market for encrypted cameras.

There have been several attempts at camera encryption. Canon used to have a product, but the encryption was hacked and not easily fixed. I think Nikon used to have something. There's a Magic Lantern firmware mod for Canon reportedly able to do encryption. Those early attempts confirm that there's not a big enough demand for encryption.

[MossyRocks]

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.