[Cryptography] ratcheting DH strengths over time

[ianG]

One of the things that is pretty clear now is that passing paramaters 
across to end users is just asking for trouble.  The end-users don't 
know what they mean, the configuration becomes a nightmare, it opens up 
downgrade attacks, consumes sysadm time, generates little or no 
measurable security and etc etc.

In times gone past, choosing public key strengths was left to the users, 
but this is a hangover from the days of PGP where you were expected to 
know what sizes meant.  Those days are gone and even RSA key sizes have 
been somewhat limited between various and many limits.  e.g., choose 
outside 2048-4096 and you risk running into one barrier or another.  But 
the notion that this number should be taken entirely out of users hands 
is not as yet popular.

However, there is an area where we might be able to win over the 
cultural argument:  DH key exchange.  In the light of the recent 
suggestion that NSA is cracking weak DH keys, we're again facing the 
same old failure:  We lack a forward thinking plan to improve the crypto 
over time to cope with circumstances.

IOW, it's easy to point out the negligence of letting users choose 
numbers, but how to remove the option?



Satoshi Nakamoto introduced the idea of a ratcheting difficulty [0], 
which increased the hardness of PoW by adding a few bits every now and 
then.  Likewise he introduced the idea of a schedule of mining rewards, 
the 25BTC thing that halves every now and then.  Both of these seem to 
have worked, in the brutal sense that they got us well into the next few 
years, and the next set of problems were revealed.

How could we do this in a DH protocol?  I would suggest a schedule over 
time.  Most or all of our implementations have a timebase available. 
Something like this:

2015 - 1024
2016 - 1280
2017 - 1536
2018 - 1792

Or, it could be done by starting with a constant for year 0 and adding 
another constant for every later year.

Then, some rules:

1.  I look up my year-size, and initiate with that number.
2.  I will accept any later year if initiated against.
3.  If asked for a bigger size, I'll have to generate/resend a new DH 
number.  This will happen on new year time, with dodgy timebases, and 
those sysadms that want to timetravel.



What difficulties are there?

  1. How would we change the schedule?  That is simple - the schedule 
will be fixed for the current version of the software.  Each new version 
comes out with its own schedule.  If you're talking v3 you use the v3 
schedule.  Upgrades are deferred to v4.

  2. The obvious bug of a missing timebase:   means that the client 
can't initiate correctly but it could just initiate with any number, and 
respond to the other's demand.  Two clients without timebase will then 
end up stuck at their default, but that's the situation now, so it isn't 
a loss.

  3. Testing is a bit of a nuisance as we'd have to wait until a year 
passes before watching them all click up.  So something of a faster 
ratchet would make sense - 20 bits every month in the above schedule.



Thoughts?  This isn't crypto per se, it's cryptography policy.  It's the 
sort of thing that should become standard in WG dox.



iang



[0] by that I mean, got it working on a large scale, not that she was 
the first person to suggest it.