[Cryptography] The Encrypted Room Re: Call for nomenclature...

[Phillip Hallam-Baker]

OK, so now need a name for this? Black chamber?

On Fri, Jun 14, 2019 at 1:54 PM #3301 <3301 at eagle.icu> wrote:

> On 6/13/19 9:58 AM, Phillip Hallam-Baker wrote:
> > [...]
> >
> > So what can I use as the name for a DARE Message?
>
>
> I like "DARE stub" and "DARE parcel." The DARE container may be a
> container of parcels or a box/crib of stubs.
>
> I would try to visualize something people are familiar with then extract
> that structure and its terms to the virtual structure of your protocol.
> Vide telegram, telegraph, radio, cable, wire, file cabinets, book
> shelves, smoke signals, pigeons, etc.
>
> Here are some possibilities:
>
> parcel - parcel packet - stub - entry - chit - post - page - leaf - card
> - message packet - word packet - communiqué - dispatch - dispatch packet
> - missive - record - imprint - transcript - correspondence - article -
> document - composition - broadcast
>

Thanks for all the suggestions. I have gone with envelope but I am thinking
I will also use parcel for a collection of envelopes.

Envelope works when I am describing things to non technical people.

Transparent envelope = wrapped plaintext
Transparent, sealed envelope = signed
Brown envelope = encrypted
Brown, sealed envelope = signed and encrypted

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.

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.

So leaving that aside, what is the closest we can get using only
unencumbered crypto?

Lets start with separation of duties

Alice writes a program
Carol operates a cloud service that receives packets of encrypted data,
processes them using the program written by Alice and returns the result

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:

Sue verifies the code and signs it

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.

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.

And of course, add crypto to taste to lock down all these relationships.

So what do we call Carol's service? It seems rather like Searle's Chinese
Room. Is it a cell? What?

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?

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.

Separation of duties minimizes opportunity to create side channels. It is
not a perfect guarantee but nothing ever is.

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.

Forensics can be divided into three parts:

1) Data collection
2) Excluding suspects
3) Identifying culprits

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20190615/92c09256/attachment.html>