[Cryptography] Long-term security (was Re: ratcheting DH strengths over time)

[John Denker]

On 11/16/2015 11:05 AM, Perry E. Metzger wrote:

> people really are doing things like putting
> building heating and elevator systems onto the internet now.

[...]

> Say you have thousands of such systems or even millions of them out in
> the field, all happily dialing home and getting new instructions, all
> that protected by an RSA key or an elliptic curve signature key. How
> do you keep that safe for a stupid amount of time?
> 
> The sad truth is, you probably can't...

I reckon we can.  I've seen good solutions to analogous problems
including much harder problems.

Suppose you buy a new car.  It has some life-limited parts.  The
original tires, filters, spark plugs, etc. are very unlikely to
last the life of the car.  Everybody knows this, and they plan
accordingly.  Installing a new air filter is not traumatic.

The same applies to bits of information.  In an airplane, there
are some charts and navigational databases that must be updated
every 56 days.  They must be updated, even if the only thing that
has changed is the expiration date.  Everybody knows this, and
they plan accordingly.  Installing an update is super-easy.

So, here's my suggestion for designing a crypto suite to last
forever:  Don't.

Instead, put an expiration date on it.  Demand that it be updated
every so often, even if the only thing that needs changing is the
expiration date.

Cars, airplanes, and elevators are already subject to periodic 
inspection in most jurisdictions.  They already have life-limited
parts that must be replaced every so often.  Software in general
-- and crypto in particular -- should be in the same category.

I'm glad the Subject: line was changed to cover the more general 
discussion.  To briefly touch on the original topic:  Ratcheting
up this-or-that parameter is not good enough, because it requires
too much perfection and too much paranormal precognition.  For
example, suppose the right move is to transition from finite-field
DH to elliptic-curve DH.  That's qualitatively different from
reparameterizing the FFDH.

Also note that (for once!) we are on the good side of the chicken
and egg question.  As for HVAC and elevators:
 *) If they don't communicate, they don't need much crypto.
 *) If they do communicate, they can be updated over the 
  communication channel.

  (This pattern doesn't cover things such as nuclear bombs, and
  it doesn't cover emergency bugfixes, but it covers quite a few 
  things, and we can use it to help keep costs down.)