[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-tls
Subject:    Re: [TLS] New Algorithm identifier for EDH > 1024 bits?
From:       Daniel Kahn Gillmor <dkg () fifthhorseman ! net>
Date:       2013-10-25 3:18:55
Message-ID: 5269E31F.3050203 () fifthhorseman ! net
[Download RAW message or body]


[picking up a slightly stale thread, sorry for the lag]

On 09/30/2013 03:28 PM, Martin Rex wrote:
> Peter Gutmann wrote:
>> Could that be because of all of the TLS_DHE_DSS_* suites, with DSS limited to
>> 1024 bits so implementers also limited the matching DH to 1024 bits?  Just
>> wondering what other reason there could possibly be for artificially limiting
>> the size to 1024 bits.
> 
> The delay incurred by key generation maybe?
> 
> The app-supplied credentials are either RSA or DSA.  So for DHE,
> _everything_ has to be newly generated after process start and potentially
> in-band during the TLS handshake, unless the application caller has
> written some code that does generation out-of-band and installs/updates
> the DHE keying material regularly.

Just to clarify, for DHE not *everything* has to be generated at
connection time or even after process start.  The DH group itself (g and
p) can be chosen (and remain static) at the time of installation or
system configuration or service initialization, and only the secret key
needs to be selected at connection time.  DH parameter generation (group
selection) is a significantly more expensive than secret key selection.

There is quite a bit of software out there that allows the administrator
to select or configure the DH parameters that will be offered by the
server while doing ephemeral Diffie-Hellman without a large delay caused
by secret generation.

Regards,

	--dkg


["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]