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