Re: [Cfrg] how can CFRG improve cryptography in the Internet?

[Daniel Kahn Gillmor <[e-mail]>]

On 02/11/2014 12:47 AM, Watson Ladd wrote:
> There is an assumption being made here: that algorithms will age
> badly. This assumption is largely unwarranted.

As the person who suggested "expiring" algorithms or protocols, i should
probably point out that this is *not* my underlying assumption.

My assumption was that we gain knowledge and experience, and in light of
the new knowledge and experience, *some* algorithms or protocols do not
hold up well (as you document clearly about hash functions and SSLv3).

In hindsight, we know which mechanisms didn't hold up; but during
deployment, that's not necessarily knowable.  Presumably we believe the
code we're deploying to be reasonably strong when we deploy it; and we
assume that it will hold up over time, but we don't know.

Introducing an "expiration" date is a mechanism for ensuring that the
software actively validates that assumption against some external source
at some point.  It's even possible that the source could say "carry on;
algorithm X should have its expiration date extended to June of 2020".

The alternative might be what we have today: a bunch of known-broken
algorithms, widely-deployed, with no clear termination date, so everyone
keeps on deploying them, because we keep expecting to need to
interoperate with these interminably-unsupportable known-bad
implementations.

If there are other ideas about how to avoid this problem besides
expiration or revocation, i'd love to hear some suggestions.  What we
have now doesn't seem to be working to get the 'net switched over to
known-good tools with any sort of plausible speed, even as known
weaknesses are present.

> Protocols with reductions remain
> secure so long as the fundamental problems they reduce to remain hard.

Even with a security reduction, it's possible that researchers discover
that the security model used with the reduction doesn't actually apply
in a real-world scenario where the algorithm was actually used; or that
the algorithm's resistance to online attack in a given instance (or with
given parameters) can be weakened with some sort of novel massive
pre-computation that we didn't expect to be feasible; or some other
break in the relationship between the model and reality that no one foresaw.

If there is consensus that any of these cryptanalysis failures happened,
having an expiration or a globalized check for revocation would provide
a way to disable a mechanism for a given use.

Regards,

	--dkg