From nmav at gnutls.org  Mon Aug  4 15:01:49 2003
From: nmav at gnutls.org (Nikos Mavroyanopoulos)
Date: Mon, 4 Aug 2003 16:01:49 +0300
Subject: [Help-gnutls] Security of RSA params
In-Reply-To: <20030725152038.GA2684@ns.snowman.net>
References: <20030725152038.GA2684@ns.snowman.net>
Message-ID: <20030804130149.GA1112@gnutls.org>

On Fri, Jul 25, 2003 at 11:20:38AM -0400, Stephen Frost wrote:
> Greetings,

>   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".
Quoting RFC2246:

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,
> 		Stephen



> _______________________________________________
> Help-gnutls mailing list
> Help-gnutls at gnu.org
> http://mail.gnu.org/mailman/listinfo/help-gnutls


-- 
Nikos Mavroyanopoulos