Monoculture

[Ian Grigg]

Matt Blaze wrote:
>
> > I imagine the Plumbers & Electricians Union must have used similar
> > arguments to enclose the business to themselves, and keep out unlicensed
> > newcomers.  "No longer acceptable" indeed.  Too much competition boys?
> >
>
> Rich,
>
> Oh come on.  Are you willfully misinterpreting what I wrote, or
> did you honestly believe that that was my intent?


Sadly, there is a shared culture amongst cryptography   
professionals that presses a certain logical, scientific 
viewpoint.

What is written in these posts (not just the present one)
does derive from that viewpoint and although one can   
quibble about the details, it does look very much from
the outside that there is an informal "Cryptographers  
Guild" in place [1].

I don't think the jury has reached an opinion on why
the cryptography group looks like a guild as yet,
and it may never do so.  A guild, of course, is either
a group of well-meaning skilled people serving the
community, or a cartel for raising prices, depending
on who is doing the answering.

But, even if a surprise to some, I think it is a fact
that the crypto community looks like and acts as if a
guild.


> I'd encourage the designer of the protocol who asked the original question
> to learn the field.  Unfortunately, he's going about it a sub-optimally.
> Instead of hoping to design a just protocol and getting others to throw
> darts at it (or bless it), he might have better luck (and learn far
> more) by looking at the recent literature of protocol design and analysis
> and trying to emulate the analysis and design process of other protocols
> when designing his own.  Then when he throws it over the wall to the rest
> of the world, the question would be not "is my protocol any good" but
> rather "are my arguments convincing and sufficient?"


This is where maybe the guild and the outside world part
ways.

The guild would like the application builder to learn the
field.  They would like him to read up on all the literature,
the analysies.  To emulate the successes and avoid the
pitfalls of those protocols that went before them.  The  
guild would like the builder to present his protocol and  
hope it be taken seriously.  The guild would like the
builder of applications to reach "acceptable" standards.

And, the guild would like the builder to take the guild
seriously, in recognition of the large amounts of time
guildmembers invest in their knowledge.



None of that is likely to happen.  The barrier to entry
into serious cryptographic protocol design is too high
for the average builder of new applications [2].  He has,
after all, an application to build.

What *is* going to happen is this:  builders will continue
to ignore the guild.  They will build their application,
and throw any old shonk crypto in there.  Then, they will
deploy their application, in the marketplace, and they will
prove it, in the marketplace.

The builder will find users, again, in the marketplace.   

At some point along this evolution, certain truths will   
become evident:  the app is successful (or not).  The code
is good enough (or not).  People get benefit (or not).
Companies with value start depending on the app (or not).
Security is adequate (or is not).  Someone comes along and
finds some easy breaches (or not).  That embarrasses (or
not).

And, maybe someone nasty comes along and starts doing
damage (or not).

What may not be clear is that the investment of the security
protocol does not earn its effort until well down the track.
And, as an unfortunate but inescapable corollary, if the app
never gets to travel the full distance of its evolutionary
path, then any effort spent up front on high-end security
is wasted.

Crypto is high up-front cost, and long term payoff.  In
such a scenario, standard finance theory would say that
if the project is risky, do not add expensive, heavy duty
crypto in up front.

This tradeoff is so strong that when we look about the
security field, we find very few applications that
succeeded when also built with security in mind from
the initial stages.

And, almost all successful apps had little or bad security
in them up front.  If they needed it later, they required
expensive add-ons.  Later on.

There are no successful systems that started with perfect
crypto, to my knowledge.  There are only perfect protocols
and successful systems.  A successful system can evolve
to enjoy a great crypto protocol, but it would seem that
a great protocol can only spoil the success of a system
in the first instance.



The best we can hope for, therefore, in the initial phase,
is a compromise: maybe the builder can be encouraged to
think about security as an add-on in the future?

Maybe some cheap and nasty crypto can be stuck in there
as a placemarker?  The equivalent of TEA or 40 bit RC4,
but in a protocol sense.

Or, maybe he can encourage a journeyman of the guild to
add the stuff in, on the side, as a fun project.

Maybe, just maybe, someone can create Bob's Simple Crypto
Library.  As a stopgap measure, as a simple little thing
that is so easy to use that even your average apps builder
wouldn't get turned away.  And just happens to be ammeniable
to replacement later on with Alice's Full & Complex Crypto
Library.


It's pretty much a given that projects will get out there
with inadequate security.  The market process for apps 
dictates that.

Although I haven't tested it, I believe it to be an
economically sound result.  The fact that this has little
to do with crypto is ... irrelevant.  That fact that the
cryptographers guild may find this uncomfortable is ... 
tough.

What remains uncertain is, when the time comes to upgrade
the security and add some real strength to an application
that cries out for help, will there be anyone there to    
help add the strength?

"Why aren't you using SSL" is basically a warning sign
to all developers that the man asking the question is a
fully paid-up member of the guild.

"Why did you do that?" is also not the right question.  

"What is your threat model?" is a far better start.

"What do you have in place right now?" is more or less
the question that Peter Guttman was asking, and that is
also a good start.

Even better would be a preamble that describes how we
need to get the threat model down on paper so that an
appropriate level of security can be put in place.


> I suppose some people will always take an anti-intellectual attitude
> toward this and congratulate themselves about how those eggheads who
> write those papers with the funny math in them don't know everything to
> excuse their own ignorance of the subject.  People like that with
> an interest in physics and engineering tend to invent a lot of
> perpetual motion machines, and spend a lot of effort fending off
> the vast establishment conspiracy that seeks to suppress their
> brilliant work.  (We've long seen such people in cipher design, but
> they seem to have ignored protocols for the most part, I guess
> because protocols are less visible and sexy).


Well, the opposition to "the guild" is one of pro-market
people who get out there and build applications.  Some
people used to call them entrepreneurs, but these days   
in the net, we think of them as just hackers, because
anyone with a code editor can be an entrepreneur.

They may sometimes say the wrong things about their own
crypto and their own security constructs - such as TINC's
"foolishly childish" attitude may have come across - but
that's just their eternel optimism and innate marketing
sense overriding any sense of absolute but irrelevant truth.

That's just them being entrepreneurs.  Don't however take
home the wrong message.  When they defend the crypto, that's
because they have a strong sense of priorities.  When they
need better crypto, then they will know it.  Because the
market will tell them.


> Rich, I know you're a smart guy with great familiarity (and
> contributions to) the field, and I know you're not a kook, but
> your comment sure would have set off my kook alarm if I didn't
> know you personally.


It's not the first time that entrepreneurs have been
called kooks :-)  It generally happens before they are
successful, though.

iang



[1] I'm ignoring the placement of the apostrophe for the
moment.

[2] We can argue the detail, but my point here is that the
barrier to entry is too high, so ignoring the guild is the
most likely result.  That said, here are some points.

It's nice that the literature is open and available.  What
is not nice is how much there is of it.  It's nice that
there is a lot of code available, and complete protocols
to boot.  What is not nice is that there is no easy way
to work out which code to use, and the protocols are not
so easy to understand.  It's nice that we have an open
community that discusses these things.  What is not nice
is that, in trying to determine the one path, the advice
of the community reduces to useless baubles like "use SSL"
or "why did you do that?"  It's great that the community
has standards, but those standards seem to be excessive
in the extreme.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com