[Help-gnutls] Security of RSA params
nmav at gnutls.org
Mon Aug 4 15:01:49 CEST 2003
On Fri, Jul 25, 2003 at 11:20:38AM -0400, Stephen Frost wrote:
> In the source code I see places where the RSA params are generated and
> there are comments like "Only do this ever day, or every 500 connects"
> or similar. I'd like to understand what the story with these params
> is. It seems they need to be regenerated every so often for the
> system to not be compramised but exactly what would happen if they
> were, and how hard is it for them to be?
The RSA parameters are only used in the so called "export ciphersuites".
D.1. Temporary RSA keys
US Export restrictions limit RSA keys used for encryption to 512
bits, but do not place any limit on lengths of RSA keys used for
signing operations. Certificates often need to be larger than 512
bits, since 512-bit RSA keys are not secure enough for high-value
transactions or for applications requiring long-term security. Some
certificates are also designated signing-only, in which case they
cannot be used for key exchange.
When the public key in the certificate cannot be used for encryption,
the server signs a temporary RSA key, which is then exchanged. In
exportable applications, the temporary RSA key should be the maximum
allowable length (i.e., 512 bits). Because 512-bit RSA keys are
relatively insecure, they should be changed often. For typical
electronic commerce applications, it is suggested that keys be
changed daily or every 500 transactions, and more often if possible.
Note that while it is acceptable to use the same temporary key for
multiple transactions, it must be signed each time it is used.
RSA key generation is a time-consuming process. In many cases, a
low-priority process can be assigned the task of key generation.
Whenever a new key is completed, the existing temporary key can be
replaced with the new one.
More reasoning is discussed in the rfc2246 paper.
> What I'm wondering, specifically, is this: Are these params given to
> the client at some point? Can they be used to derive the session key?
> Most importantly: Can one client decrypt another client's session
> trivially if the same RSA params are used for both?
No. It is not trivial.
> OpenLDAP has been ported to use GNU TLS but it is currently not
> explicitly generating/setting the RSA params. From what I've read
> these params are probably generated on the fly by GNU TLS for every
> session because of this. This causes a significant increase in the
Gnutls will not generate the parameters. If an export ciphersuite is
negotiated, it will fail with an error of missing rsa parameters or so.
> CPU utilization of the slapd processes. Other programs (exim, for
> example) appear to generate these params and then save them for use
> with multiple sessions. Should OpenLDAP do the same? Would security
> be compramised by doing this?
This is the recommended way to do it. You should have a way to regenerate
them after some time (especially the RSA parameters).
> Many thanks,
> Help-gnutls mailing list
> Help-gnutls at gnu.org
More information about the Gnutls-help