[Cryptography] RSA equivalent key length/strength

Viktor Dukhovni cryptography at dukhovni.org
Sat Sep 28 13:34:48 EDT 2013


On Fri, Sep 27, 2013 at 11:23:27AM -0400, Phillip Hallam-Baker wrote:

> Actually, it turns out that the problem is that the client croaks if the
> server tries to use a key size that is bigger than it can handle. Which
> means that there is no practical way to address it server side within the
> current specs.

Or smaller (e.g. GnuTLS minimum client-side EDH strength).  And
given that with EDH there is as yet no TLS extension that allows
the client to advertise the range of supported EDH key lengths (
with EECDH the client can communicate supported curves), there is
no timely incremental path to stronger EDH parameters.

In addition to the protocol obstacles we also have API obstacles,
since the protocol values need to be communicated to applications
that provide appropriate parameters for the selected strength
(EDH or EECDH).

In OpenSSL 1.0.2 there is apparently a new interface for server-side
EECDH curve selection that takes client capabilities into account.
For EDH there is need for an appropriate new extension, and new
interfaces to pass the parameters to the server application.

Deploying more capable software will take a O(10 years).  We could
perhaps get there a bit faster, if the toolkits selected from a
fixed set of suitable parameters and did not require application
changes, but this has the drawback of juicier targets for cryptanalysis.

So multiple things need to be done:

    - For now enable 1024-bit EDH with different parameters at each server,
      changed from time to time.  Avoid non-interoperable parameter choices,
      that is counter-productive.

    - Publish a new TLS extension that allows clients to publish supported
      EDH parameter sizes.  Extend TLS toolkit APIs to expose this range
      to the server application.  Upgrade toolkit client software to advertise
      the supported EDH parameter range.

    - Enable EECDH with secp256r1 (and friends) unless it is
      reasonably believed to be cooked for efficient DLP by its creators.

    - Standardize new EECDH curves (e.g. DJB's Curve1174).

-- 
	Viktor.

P. S.

For SMTP transport security deploy DNSSEC and DANE TLSA.  I'm hoping
at least one of the larger service providers will do this in the
not too distant future.

Postfix (2.11 official release 2.11) will support this in early
2014.  Exim will take a bit longer, as they're cutting a release
now, and the DANE support is not yet there.  The other MTAs will
I hope follow along in due course.

The SMTP backbone (inter-domain SMTP via MX records, ...) can be
upgraded to use downgrade-resistant authenticated TLS.


More information about the cryptography mailing list