Originally published at: http://boingboing.net/2017/07/13/no-passwords-needed.html
…
3 Likes
Feature suggestions:
A one-time preview of the image just snapped could still happen.
- After the moment, on-device retrieval would not be possible.
Encryption could be turned on and off via a switch
- leading to steganographic possibility: fraction (every Nth pixel) of encrypted image is surreptitiously embeded into/across multiple unencrypted (banal) images. Would appear as “noise” on the banal images, but could be extracted and reassembled.
5 Likes
Another issue is the ability to authenticate that the photo was not edited after the fact. I’d like to see cameras that are networked (like, say, tethered to a cell-phone) be able to submit a hash of the image to a public blockchain. That way there is a public record of time and date that the photo was taken. Then photos with anomalous (or missing) blockchain records won’t be considered trustworthy.
6 Likes
Another possibility could be to have lower res copies of the pictures (encrypted more than likely as well) also available in case a photographer wants to quickly be able to sync those to the cloud or other device in case the memory storage is taken or confiscated from the photographer.
3 Likes
You could go one step further, publish the encrypted photo at the time it’s taken (may not be possible in all scenarios) and later you could release the unmodified decrypted photo and the public key to prove it’s providence. Any one with the both of these items could re-encrypt to get the original published cyper-photo.
Thumbnail images for a quicker send on lousy/slow uplink! Publisher/editor could then request only the most desirable full images for immediate transmission.
2 Likes
First thoughts: You could bypass a lot of the negatives just by having a little extra RAM on the device to hold an unencrypted version of the latest picture (or the previous few) in volatile storage. You’ll then get most of the benefits of a digital camera such as image review, but hit the power button and it’s instantly the encrypted version only.
5 Likes
Yeah i was thinking having a file size that would be good for fast uploads. It would be interesting to have it “curated” in near real time by an editor off site and request the RAW pictures to sync as needed.
Basically just a git commit. You can do it with github or a similar service. No additional cloud service required.
Not without the private key though.
Git repositories are not tamper resistant, with enough mirrors you can verify a change in history was made, but it’s trivial (and built in) to rewrite history and overwrite the old history of a remote repository.
Umm… in the scenario described in the article the Public Key is used to encrypt on the cammera, Private to decrypt. So raw image + Public Key = encrypted image. My statement stands, you never need to publish the Private Key, only the encrypted image as it’s taken, and any time later both the decrypted image and the Public Key.
You never give any one the ability to decrypt any encrypted images, but the can repeat the encryption step to verify that a raw image was indeed published at a prior date.
1 Like
$ avconv -f video4linux2 -i /dev/video0 -ss 0:0:2 -frames 1 -f mjpeg - | gpg -e -s -r who@inter.web > $(date +%s).jpg.gpg
Here’s a command that captures an image then encrypts it along with a signature.
Get a GNU system and a webcam and try it out! 
I see what u did dere…
Oh wow, as a complete accident of a quote, that still works 
1 Like
This topic was automatically closed after 5 days. New replies are no longer allowed.
