<div dir="ltr">A fascinating point about the perception of encryption vs. the reality of encryption.  Can we break this discussion down a bit?<div><br></div><div>What I mean is, if still and video footage has issues, what are the issues, and what are some solutions to those issues? A knee-jerk jump to "Encryption Magic will SAVE THE DAY!!" might not be the right answer. :) Forgive the levity. </div><div><br></div><div>Issues:</div><div>1. Unauthorized editing of video or stills</div><div>2. Pressure, ranging to duress, to delete stills or video</div><div>3. Pressure, ranging to duress, to view stills or video</div><div>4. Unauthorized recording of information - Example - I don't want precise location tags on a pic, to protect a source, but the camera does so without my consent or knowledge.</div><div>5. Verifiably "correct" stills or video - I know this content has not been altered. (Different from #1, unauthorized editing, in that #1 is more about access control, and this is more about forensic verifiability)</div><div><br></div><div>So, I am probably missing a few. Please feel free to add.</div><div><br></div><div>My initial thoughts, and again, please feel free to point and laugh.</div><div><br></div><div>2 and 3 are solved with remote storage, to a "safe" place, of the stills or video. Take it off the camera, fast.</div><div>4 is only solved if you open source the camera software and firmware, and that's probably not going to happen.</div><div>1 and 5 can be solved by hashing frames, and interlocking sequences of frames. Hash Frame 1,2,3,4,5. Hash Frames 1-5, and 5-9, and 9-14. I can then tell you if any single frame has been altered, and if anybody has tried to add anything to the stream.</div><div><br></div><div>I'm possibly being naive, but I don't see encryption (past hashing) as needed. tell me where I'm wrong?</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 20, 2016 at 10:14 AM, Peter Todd <span dir="ltr"><<a href="mailto:pete@petertodd.org" target="_blank">pete@petertodd.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, Dec 19, 2016 at 10:30:50PM +0000, Ben Laurie wrote:<br>
> > But public key encryption provides another option: encrypt the pix with someone's *public key*; the *private key* is unknown to the photographer.<br>
> ><br>
> > So far as the photographer is concerned, the pix storage is a black hole, which can only be entered by means of the private key.<br>
> ><br>
> > Yes, the storage can be destroyed (if it can be found); thus, it would be better to transmit it in real time -- e.g., ACLU's "Mobile Justice" app for recording police activities.<br>
> ><br>
> > (I don't know if ACLU's "Mobile Justice" app encrypts or not, nor whether it uses PKI if it does encrypt.)<br>
><br>
> I guess your one comfort in enhanced interrogation will be that<br>
> there's no way to make it stop.<br>
<br>
</span>Don't get too dramatic; there's lots of countries where rule of law is<br>
sufficiently respected that the consequences of being unable to decrypt are<br>
tolerable, while the consequences of being *able* to decrypt are unacceptable.<br>
<br>
For starters, most western democracies fall into that category.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
<a href="https://petertodd.org" rel="noreferrer" target="_blank">https://petertodd.org</a> 'peter'[:-1]@<a href="http://petertodd.org" rel="noreferrer" target="_blank">petertodd.org</a><br>
</font></span><br>______________________________<wbr>_________________<br>
The cryptography mailing list<br>
<a href="mailto:cryptography@metzdowd.com">cryptography@metzdowd.com</a><br>
<a href="http://www.metzdowd.com/mailman/listinfo/cryptography" rel="noreferrer" target="_blank">http://www.metzdowd.com/<wbr>mailman/listinfo/cryptography</a><br></blockquote></div><br></div>