[Cryptography] ratcheting DH strengths over time

[Michael Kjörling]

On 16 Nov 2015 11:06 -0500, from perry at piermont.com (Perry E. Metzger):
> So, how does one automatically upgrade not only the strength of the
> asymmetric subsystem but also the symmetric ciphers and hashes in use?
> I'm not sure one does -- so perhaps the auto upgrade point is
> moot. Perhaps you just make sure you never use a "bad mix" where the
> key strengths are out of line with each other and beyond that you hope
> that people aren't stupid about their engineering decisions for long
> lived hardware.

That would seem to depend on where the perceived weakest link is. Take
keylength.com's numbers, for example: if I plug in a 2048 bit
factoring modulus size, I get back various figures that point toward a
100-128 bit work factor. In other words, for symmetric crypto, a
fairly good match for AES-128: neither is obviously weaker than the
other.

However, both 192-bit and 256-bit AES are readily available,
standardized and well understood. Again taking keylength.com's numbers
at face value, to match a 256-bit AES encryption we'd need to use RSA
with moduli anywhere between 15,000 and 50,000 bits. This is _clearly_
_far beyond_ what counts as practical in anything but extremely
specialized workloads.

It would be trivial to set a date, or threshold, by which conformant
implementations should switch from, say, 128-bit AES to 192-bit AES.
This can be done _well_ in advance, long before any practical attack
on 128-bit AES is known, simply such that the symmetric cipher does
not become the weakest link. This seems reasonable to me because the
performance penalty of going with longer symmetric keys, for example
in the case of AES, is much smaller than the performance penalty of
going with longer asymmetric keys.

(Or if we're worried about quantum computers, we could just go to
256-bit AES at once for a 2^128 WF for a quantum capable adversary,
and skip the intermediate step. But then again we would need to solve
the key exchange problem in the post-quantum-computers world, or we
are back to the steel walls and paper door.)

I don't know what sort of impact this would have on embedded systems,
but for applications that have access to decent amounts of processing
power, the switch from AES-128 to even AES-256 should for most
practical purposes barely be noticable, and if it is noticable and a
problem, it is at least _relatively_ easy to throw more hardware at
the problem. (Not quite so easy with embedded systems.)

_Yes_, an attacker will go after the whole system. But I don't think
that's a reason for not _making each primitive as strong as is
reasonable_ within a given set of performance criteria on a given set
of hardware.

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)