[Cryptography] ratcheting DH strengths over time

[Perry E. Metzger]

On Mon, 16 Nov 2015 00:10:09 +0000 ianG <iang at iang.org> wrote:
> [Suggests that software should up key sizes, DH group sizes,
> etc. automatically with time, taking the decision to do so out of
> user hands.]

There's an old adage that software lives longer than hardware, and I
think this does make sense if only because it takes certain kinds of
decisions away not only from end users but also from release
engineers, system integrators, and others who likely aren't going to
spend a lot of time thinking about things like the DH moduli their
systems ship with.

That said, I do worry about the effect of such schedules in the one
place that hardware lives ridiculously long, which is embedded
hardware. Often, small embedded controllers remain in place for insane
periods of time, sometimes vastly longer than anyone had originally
envisioned, and an underpowered controller that communicates very
nicely with a key of size N might not handle a key of size 3N nearly
so well. Furthermore, engineers are unlikely test their equipment with
the date set twenty years into the future near the End of Life.

Ideally, one should set the constants on such controllers to the ones
that will be viable at the end of life (say picking likely end of
manufacturer sale plus thirty years), thus forcing the designers to
confront not just today's computing needs but possibly tomorrows --
but it also seems unlikely that we can get engineers to do that.

So, I suppose my overall comment is: this is an interesting idea, but I
suspect it will not be entirely easy to make work, especially in the
places where it is most needed (that is, hardware being kept around
way past the point where it should be retired.)

Regardless, let me remind almost everyone that the main problem in the
recent Logjam attacks was a combination of a downgrade attack and the
fact that engineers had forgotten that DH primes really should not be
shared by everyone on earth. One could easily mis-engineer future
systems so that they upped the sizes of various keys and groups and
yet remained vulnerable to things like downgrade attacks etc. Once
again, people tend not to attack cryptography head on, but to find
weak points and go after *those*.


Perry
-- 
Perry E. Metzger		perry at piermont.com