[gnutls-dev] Generating/regenerating params

Nikos Mavroyanopoulos nmav at gnutls.org
Sun Mar 7 18:59:35 CET 2004

On Sat, Mar 06, 2004 at 02:19:31AM -0500, Stephen Frost wrote:

> Greetings,
>   I've run into a very difficult problem when trying to safely
>   regenerate dh/rsa parameters.  The setup is like this:
>   There's a global context which has creds
>   (gnutls_certificate_credentials) and all of the CA certs and whatnot
>   are loaded into it.
>   We then have a local (per thread) context which copies the cred from 
>   the global context, but just the pointer (there isn't a function to
>   copy the whole thing...).
There is no need to copy the whole thing, since the credentials
are only read by the sessions. They are never modified.

>   We then set params in creds in each thread, cacheing the params in a
>   file and regenerating the params whenever the file disappears, which
>   we plan to make happen periodically as is recommended in various
>   comments in the example GNU TLS server.
>   There's a couple problems here though:  The params are shared across
>   all threads because of the single global context with creds.  I worry
>   about regenerating them because I don't want to break existing
>   connections or ones which are in the process of setting up.  I don't
>   see any way (beyond re-reading all the certs which I expect would kill
>   performance) to make the creds be local though.
>   What's the right way to do this?  Have multiple threads going and
>   still periodically regenerate the rsa/dh params without breaking
>   anything or leaking memory or anything?  Is it safe to just init the
>   rsa/dh params and then just change them with generate2 or import_raw?
>   Will that break existing connections or other threads which are
>   setting up their connections?  Do I still need to call set_XX_params?

Currently there is no easy way to renew that parameters in multithreaded 
applications. I was thinking into adding functions or callbacks to set those 
parameters per session. Would this solve your problem?

>   	Thanks,
> 		Stephen

Nikos Mavroyanopoulos

More information about the Gnutls-devel mailing list