[gnutls-dev] Re: living without global variables

[Bryan Henderson]

>The major reason for global state is the entropy pool.

I suspected that, which is why it's very much a policy matter.  How
much entropy generation time savings is the user willing to pay for?
Is it worth adding extra complexity for users of one's library (which
uses Libgcrypt under the covers)?

Besides, it's really rather arbitrary to throw the entropy-sharing net
around the program (technically, it's the program, not the process,
since it starts over with each exec).  It might just as well go around
one subsystem within the program or the work of one user, or the whole
computer system, or more.

I'm not at all comfortable having my encryption library know what a
process is, and even less comfortable having it know what a thread is.

All of which is to say that if Libgcrypt used private contexts (an
initialization function returns a handle; other functions take that
handle) instead of global variables, it would have thread-safety and
whatever entropy pooling level the code above wants.  Without
Libgcrypt knowing what a thread, process, or program is.  As a
practical matter, a typical program won't make a context for each
session; just one for each module in the program, which would be like
3 at the most, and usually 1.  Multiple modules could share the same
Libgcrypt context (and entropy pool) if they did so expressly, just by
having their common caller create one and pass it in.

I don't really know much about encryption, but don't some OS kernels have
device drivers that provide a computer-wide entropy pool?

>Another one is libgcrypt's "secure" memory allocation
>functions - obviously this can't be done on a per session base or
>delegated to a daemon.

I don't know how that works; it isn't obvious why each session or,
more relevantly, "user" couldn't do this independently.

-- 
Bryan Henderson                                    Phone 408-621-2000
San Jose, California