|Applies To||RSA BSAFE Cert-C|
|Issue||Program hangs in C_InitializeCertC()|
Program hangs in C_InitializeCertC()
If the log provider is registered first, and then the default crypto service provider, the log file (rsacertc.log) will show any errors. e.g.
The log shows that not enough bytes of entropy could be read from /dev/random. You can use /dev/urandom instead.
/* enable the user to set an environment variable to change where
random_device = getenv("DEVRANDOM");
From `man urandom`:
"When read, the /dev/random device will only return random bytes within the estimated number of bits of noise in the entropy pool. /dev/random should be suitable for uses that need very high quality randomness such as one-time pad or key generation. When the entropy pool is empty, reads from /dev/random will block until additional environmental noise is gathered.
When read, /dev/urandom device will return as many bytes as are requested."
To set an environment variable programmatically, you can call putenv().
status = putenv("DEVRANDOM=/dev/urandom");
Switching from /dev/random to /dev/urandom, does have security implications, since /dev/urandom returns bits that contain less entropy than those returned by /dev/random. Cert-C uses the rsacsp.c provider to seed all of it's pseudo random operations.
If you modify the rsacsp.c provider, you can change the way it works to strengthen the entropy gathering process. For instance, you could have /dev/urandom return more bits. If the bits returned by /dev/urandom contain a relatively constant amount of entropy (this would need to be verified), then more seed bits would contain more entropy. Alternatively, you could use other sources of entropy. In rsacsp.c, RSA_UpdateRandomUnix() uses the addDevRandomEntropy() function (shown above) as only one of several entropy sources. The relative security of any of these methods would need to be verified by someone other than RSA Support.
|Legacy Article ID||a39768|