[Cryptography] Making models + scenarios realistic

[John Denker]

On 4/13/19 8:02 AM, Phillip Hallam-Baker wrote in part:

> So the reason Alice and Bob are worried about Eve overhearing their
> conversations is that Alice is married to Eave but she really wants to have
> an affair with Bob who is really interested but a little worried that Alice
> might turn out to be an axe murderer. And yes, Alice does have an axe
> hidden under her bed because she is 4'11" tall weighing less than 100lb and
> Bob is the Naval mixed martial arts champion.

But is she /exactly/ 4'11" ????

> My point here is not humorous.

Yet the scenario is ludicrous.  The rococo details tell us that
this scenario covers a set of measure zero in a very large space.

Scenarios are infinitely important, but other considerations
are also infinitely important.  In particular, you have to have
some sort of /model/.  It's like high-school chemistry, where
you collected some data points and then fitted a straight line
to them:
 -- The line is the model, with some adjustable parameters.  It
  allows you to interpolate between the data points, and to
  extrapolate.
 -- Scenarios play the role of data points.  They allow you to
  pin down the adjustable parameters in the model.

A good model incorporates your /understanding/ of the situation.
This understanding allows you to limit the number of parameters
in the model, which in turn reduces the number of scenarios that
are needed to constrain and test the model.

> brittle

Yes.  Data points by themselves are infinitely brittle.  They
have measure zero in a very large space.

Three of the smartest guys I know just got the Turing prize for
work that revolves around this principle:
 *Without the model the scenarios are useless ... and vice versa.*

   https://www.vox.com/future-perfect/2019/4/4/18294978/ai-turing-award-neural-networks
   https://www.wired.com/story/godfathers-ai-boom-win-computings-highest-honor/

> people ask me about that scenario all the time.
> 
> Ooops, sorry. Nobody has ever asked me about it, they just did it anyway
> knowing that there was a risk even though they were worried about it at the
> time.

Not only have they not asked;  they wouldn't have had a
language to use for asking the question even if they wanted
to, even if they realized it was an important question.
They would have had no way to specify which details of the
situation are important to them and which are not.

> The cryptography is the easy part.

Yes.

> The hard part is working out what the scenarios should be.

Again:  The scenarios are absolutely necessary but they are
not the only hard part, or even the hardest part.  One must
also have a sharable understanding of what the security
model is /supposed/ to do.  Scenarios can be used to test
understanding, but they do not create understanding.

A model is tantamount to a formal language for specifying
what you want.  As always, language design is only secondarily
a language issue;  understanding has to come first.  Otherwise
the language becomes impossibly complex and inscrutable, to
the point where it is useless even to experts, not to mention
laypersons such as Alice.

Offering an encyclopedia of scenarios and asking Alice to
choose one is not feasible.

I once had a student pilot who didn't want to build explicit
mental models of the situation.  She just wanted to practice
until she had seen all the scenarios.  I explained that during
landing there are 12 different things you need to worry about.
If we oversimplify it to the point where each variable can
have only three different values (high, nominal, and low) that
still leaves us with half a million scenarios, and it would be
spectacularly infeasible to learn them all by rote.  Instead
you must use /understanding/ in order to factor one infeasible
problem into 12 feasible problems, and then master those.

Obviously we have "some" understanding of what security policies
are supposed to do, but I'm not convinced it is enough, except
perhaps in certain tightly circumscribed micro-domains.  For
example, consider the PGP "web of trust".  What does that even
mean?  For one thing, trust is not transitive, and secondly,
trust is hard to quantify.  It's not even one-dimensional.  I
have some neighbors whom I would trust to borrow the proverbial
cup of sugar but wouldn't trust to borrow my car or my credit
card.

Also:  The /language/ issue runs both ways:
 -- We need a way for Alice to tell her IT guy what she wants.
 -- We also need a way for Hillary's IT guy to tell her about
  the threats, in a way that she understands, e.g. that maybe
  the inconvenience of using two-factor authentication is
  small compared to the inconvenience of having your campaign
  pillaged and burned by Fancy Bear.

Bottom line:  A floridly detailed scenario is, ironically, a
way of illustrating the limitations of scenarios.  We also
need models aka languages and (!) understanding.