Make PRNG instances static class members to avoid long encrypter object initialisation

[Vladimir Dzhuvinov]

Details of the issue from the email thread:

---

Hello Valdimir,

Once should be enough - if the seed is of sufficient quality, and the PRNG has a big enough period.

The PRNG should be used in a configuration like this..

ftp://ftp.rsasecurity.com/pub/pdfs/bull-1.pdf

(except don't use MD5!)

Mike

From: Vladimir Dzhuvinov / NimbusDS [[e-mail]] Sent: 14 May 2013 14:51 To: Mike Scott Subject: PRNG reseeding in Nimbus JOSE+JWT library

Hello Michael,

I wish to ask you for advice on whether PRNG re-seeding is required, from a security perspective, in long running (months, possibly even years) PRNG instances.

In the Nimbus JOSE+JWT library we use Java's built-in PRNG in the various encrypter classes. For each encrypter instance we create a new PRNG, but we found out, through tests, that the initial seeding of the PRNG can occasionally take up to 1 second, which is not acceptable for producing JWT tokens in concerned apps. A solution to avoid this temporary lock up is to make the PRNG a static class member, which would cause the initial seeding to be done just once, at server startup. But are there any security implications in using the same PRNG for a long time?

Thanks,

Vladimir

On Tue, 2013-05-14 at 15:03 +0200, Juraj Somorovsky wrote: I found an interesting best practice article about PRNG best practices:

http://www.e-zest.net/blog/generating-secure-random-numbers/

However, it does not mention, how often to reseed a PRNG. I would be also interested in knowing the answer to this question, but I could find anything helpful.

Regards Juraj

On 05/14/2013 12:58 PM, Vladimir Dzhuvinov / NimbusDS wrote:

Thanks for the info on seeding the PRNG Juraj.

I have question: is there some recommended period - hours, days - after which the PRNG should be reseeded (using the original method, maybe internally)? In other words, for how long is it safe to use a particular PRNG instance once it's seeded? In a server-side scenario we could have encrypter classes created once and possibly running for months and years.

Cheers,

Vladimir

Vladimir Dzhuvinov : www.NimbusDS.com http://www.NimbusDS.com : [e-mail] [e-mail]

[Vladimir Dzhuvinov]

Done in commit dd9dcf5 .