<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">OK, so now need a name for this? Black chamber?</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 14, 2019 at 1:54 PM #3301 <3301@eagle.icu> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 6/13/19 9:58 AM, Phillip Hallam-Baker wrote:<br>
> [...]<br>
><br>
> So what can I use as the name for a DARE Message?<br>
<br>
<br>
I like "DARE stub" and "DARE parcel." The DARE container may be a<br>
container of parcels or a box/crib of stubs.<br>
<br>
I would try to visualize something people are familiar with then extract<br>
that structure and its terms to the virtual structure of your protocol.<br>
Vide telegram, telegraph, radio, cable, wire, file cabinets, book<br>
shelves, smoke signals, pigeons, etc.<br>
<br>
Here are some possibilities:<br>
<br>
parcel - parcel packet - stub - entry - chit - post - page - leaf - card<br>
- message packet - word packet - communiqué - dispatch - dispatch packet<br>
- missive - record - imprint - transcript - correspondence - article -<br>
document - composition - broadcast<br></blockquote><div><br></div><div class="gmail_default" style="font-size:small">Thanks for all the suggestions. I have gone with envelope but I am thinking I will also use parcel for a collection of envelopes.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Envelope works when I am describing things to non technical people.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Transparent envelope = wrapped plaintext</div><div class="gmail_default" style="font-size:small">Transparent, sealed envelope = signed</div><div class="gmail_default" style="font-size:small">Brown envelope = encrypted</div><div class="gmail_default" style="font-size:small">Brown, sealed envelope = signed and encrypted</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So now the challenge is to find a name for a metaphor for a general approach to a problem that occurs in medicine and home automation.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I don't see how true homeomorphic encryption is feasible. That is the ability to perform an algorithm on encrypted data without decrypting it. The Fourier transform apart, almost every interesting analysis technique requires conditionals. Most interesting algorithms are np-complete asymptotically but have efficient solutions or efficient approximations that exploit the structure of the data. Any optimization that makes use of such structure in the data must reveal such structure and thus disclose information about the content. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So leaving that aside, what is the closest we can get using only unencumbered crypto?</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Lets start with separation of duties</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Alice writes a program </div><div class="gmail_default" style="font-size:small">Carol operates a cloud service that receives packets of encrypted data, processes them using the program written by Alice and returns the result</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">This system works up to a point but requires more trust in Alice and Carol than is necessary. Is Alice going to introduce malicious code? Is Carol going to keep the decrypted data? Lets introduce more parties:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Sue verifies the code and signs it<br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Vera writes code that observes the inputs and outputs of the code provided by Alice and checks to see that they are consistent with the specification of the code. If this is the case, the result is signed, otherwise an exception is signaled.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Gordon acts as a gatekeeper, he receives requests from customers, strips out the identifying detail, submits them to Carol and receives back the result which he returns to the customer who asked for it.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">And of course, add crypto to taste to lock down all these relationships. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So what do we call Carol's service? It seems rather like Searle's Chinese Room. Is it a cell? What?</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">And it need not be a program doing this work and it need not be a cloud service. I believe we should adopt precisely the same approach to security if we are doing a sensitive operation on a local compute service as on a third party service. So I might outsource my voice recognition to Alexa or Siri if they provide a hard anonymization service like the one outlined above but if I am more privacy conscious and want to run it on the device I own and operate personally? Why wouldn't I want the exact same set of cryptographic protections in case I have been sold a compromized device?</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The approach I am advocating here is radical distrust. We start from the assumption that at least some parts of our system are compromized and look to mitigate the consequences. This has two prongs, first applying the principle of least privilege at a granular level, second examining the behavior of modules to check that they are operating correctly. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Separation of duties minimizes opportunity to create side channels. It is not a perfect guarantee but nothing ever is.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The immediate applications I see for this approach are for privacy sensitive applications like analyzing voice, X-rays and MRIs to detect cancer, etc. etc. But the same approach could be applied to forensic examinations.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Forensics can be divided into three parts:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">1) Data collection</div><div class="gmail_default" style="font-size:small">2) Excluding suspects</div><div class="gmail_default" style="font-size:small">3) Identifying culprits</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The first two are relatively uncontroversial (but many practices are awful and sloppy). The third is coming under serious challenge of late as it is pointed out that while it is clear that Xavier didn't open the safe if he fingerprints don't match, the claim that a match confirms it must have been Xavier is no longer as certain.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So deploying this approach to operations performed by human technicians, we would include quality monitoring and constantly rank labs according to empirical measures. We would use the same anonymizing approach and add some blockchain (the VCs would insist if we didn't) to provide some non repudiability. </div><div class="gmail_default" style="font-size:small"><br></div></div></div>