this plugin is about 80% of the way there when it comes to solving some big real-world problems... consider the following:
1. The journalist
After taking some photos of a protest, a journalist is detained by the police. They want the journalist's photos so they can prosecute the demonstrators, prosecute the journalist, or (more probably) both.
The journalist gives them his camera, but warns, "the photos are encrypted, so it won't be much use to you."
"What do you mean, encrypted?" the police ask. "What's the password? Tell us the password or we'll lock you up."
"I don't have the password," the journalist replies. "I can't decrypt the photos after I take them. The decryption key is with my editor in Paris. I take the photos, upload the encrypted photos to our server, and then my editor decrypts, edits, and publishes them. Am I free to go?"
Setting this up is easy: the publication's tech department supplies the journalist with a plain-text config file containing the public key and other settings. The journalist copies the config file to all of his memory cards. The camera firmware automatically recognises the config file and encrypts the photos as specified.
(Writing a user-friendly GUI to generate the config and handle decryption of photos should be easy, but can wait until the basic functionality is in place.
Similarly, verifying the key is correct by generating a key-fingerprint-image and displaying it on screen when the camera is turned on may also be worth doing... later.)
2. The forensic investigator
Before taking photos of a crime scene, the investigator generates a new time-stamped public-private key pair using a menu in the camera. The camera stores the private (signing) key in memory -- it's never written to the memory card and can't easily be extracted.
Instead, the camera writes the public (verification) key to the memory card, along with signed metadata about when and how the key-pair was generated. (camera serial number, etc)
Then, every time the camera takes a photo, it writes a cryptographic signature for the entire data file to the memory card. Using the public key (which was written to the card), anyone can verify a given digital image was taken by that camera at that time, and hasn't been modified since.
## Suggestions for implementation
There are a couple of things that would be helpful to make it the last 20% of the way:
- Implement real encryption: For people who need encryption or signing, performance is a secondary concern. Being able to gawk at your photos on the camera is also not so important if being able to do so puts your life and/or freedom at risk. (on-camera decryption is very much of secondary importance and could be implemented later)
- Use established cryptography instead of DIY: Implementing "real" encryption isn't hard. Compact, efficient cryptosystems (like Filo Sottile's `age` / `rage` ecosystem) are widely available and offer good flexibility. They've also been reviewed for vulnerabilities and errors -- that's not true of anything we might come up with.
- Modularize the encryption: As soon as this sees any real-world use, encryption experts are going to look at it and point out ways we can do it better. Maybe next year someone will discover a crucial flaw in the fabric of reality and we will have to switch to some kind of Super Post-Quantum Isogenic-Singularity algorithm. Either way, the more modular and decoupled the encryption/signing code is from everything else, the easier it will be to implement these inevitable fixes.
- Make the interface conceptually simple and based on established standards... then add newbie-friendly sugar later. Putting an encryption key on the memory card (or reading a verification key from that card) is very basic. Editing a TOML or INI file by hand is also easy. Later on, it's easy to write a user-friendly GUI wrapper which generates the key, writes the config file... and then once the photos are taken, decrypts the photos.
1. The journalist
After taking some photos of a protest, a journalist is detained by the police. They want the journalist's photos so they can prosecute the demonstrators, prosecute the journalist, or (more probably) both.
The journalist gives them his camera, but warns, "the photos are encrypted, so it won't be much use to you."
"What do you mean, encrypted?" the police ask. "What's the password? Tell us the password or we'll lock you up."
"I don't have the password," the journalist replies. "I can't decrypt the photos after I take them. The decryption key is with my editor in Paris. I take the photos, upload the encrypted photos to our server, and then my editor decrypts, edits, and publishes them. Am I free to go?"
Setting this up is easy: the publication's tech department supplies the journalist with a plain-text config file containing the public key and other settings. The journalist copies the config file to all of his memory cards. The camera firmware automatically recognises the config file and encrypts the photos as specified.
(Writing a user-friendly GUI to generate the config and handle decryption of photos should be easy, but can wait until the basic functionality is in place.
Similarly, verifying the key is correct by generating a key-fingerprint-image and displaying it on screen when the camera is turned on may also be worth doing... later.)
2. The forensic investigator
Before taking photos of a crime scene, the investigator generates a new time-stamped public-private key pair using a menu in the camera. The camera stores the private (signing) key in memory -- it's never written to the memory card and can't easily be extracted.
Instead, the camera writes the public (verification) key to the memory card, along with signed metadata about when and how the key-pair was generated. (camera serial number, etc)
Then, every time the camera takes a photo, it writes a cryptographic signature for the entire data file to the memory card. Using the public key (which was written to the card), anyone can verify a given digital image was taken by that camera at that time, and hasn't been modified since.
## Suggestions for implementation
There are a couple of things that would be helpful to make it the last 20% of the way:
- Implement real encryption: For people who need encryption or signing, performance is a secondary concern. Being able to gawk at your photos on the camera is also not so important if being able to do so puts your life and/or freedom at risk. (on-camera decryption is very much of secondary importance and could be implemented later)
- Use established cryptography instead of DIY: Implementing "real" encryption isn't hard. Compact, efficient cryptosystems (like Filo Sottile's `age` / `rage` ecosystem) are widely available and offer good flexibility. They've also been reviewed for vulnerabilities and errors -- that's not true of anything we might come up with.
- Modularize the encryption: As soon as this sees any real-world use, encryption experts are going to look at it and point out ways we can do it better. Maybe next year someone will discover a crucial flaw in the fabric of reality and we will have to switch to some kind of Super Post-Quantum Isogenic-Singularity algorithm. Either way, the more modular and decoupled the encryption/signing code is from everything else, the easier it will be to implement these inevitable fixes.
- Make the interface conceptually simple and based on established standards... then add newbie-friendly sugar later. Putting an encryption key on the memory card (or reading a verification key from that card) is very basic. Editing a TOML or INI file by hand is also easy. Later on, it's easy to write a user-friendly GUI wrapper which generates the key, writes the config file... and then once the photos are taken, decrypts the photos.