[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[cp-patches] Re: RFC: GNU Crypto and Jessie (again)

From: Casey Marshall
Subject: [cp-patches] Re: RFC: GNU Crypto and Jessie (again)
Date: Mon, 23 Jan 2006 11:28:51 -0800

On Jan 23, 2006, at 9:34 AM, Raif S. Naffah wrote:

hello Casey,

On Monday 23 January 2006 16:31, Casey Marshall wrote:
On Jan 22, 2006, at 3:19 PM, Mark Wielaard wrote:
On Sat, 2006-01-21 at 19:06 -0800, Casey Marshall wrote:
I've finished splitting GNU Crypto along "weak" and "strong"
lines, reformatted the code in GNU Crypto, and added the correct
copyright headers to all the files. The resulting patch, and zip
file of new files is here:


i see that the utility class PRNG has been removed and its uses have
been replaced by (potentially multiple) "new SecureRandom()"
invocations.  wouldn't it be more efficient to keep PRNG and re-write
it to use the CSPRNG if/when present (by reflection as you did with the
KeyPairGeneratorFactory), or seed the MDGenerator?

I'm dissatisfied with the whole approach of using a singleton like that; many parts of the JCE allow you to specify a SecureRandom when creating crypto objects that require random bytes, and using that singleton breaks that. I changed Jessie too, so that it only ever uses the SecureRandom that the user specified (or, naturally, the default one if none was given). Users should be able to specify the PRNG they want; we don't want to provide an ultra-secure RNG to someone who doesn't require one, and likewise don't want to use a weak RNG when a strong one is required. And sharing random bits is unwise.

Eventually, I'd rather see all those `new SecureRandom' instances replaced by parameters wherever possible. But I thought the PRNG singleton was more of a wrong approach than this, so I removed it. I seriously doubt that anyone would notice or care that we use one additional, short-lived object instead of a single static instance, and a shared global like that can be *less* efficient in a highly multithreaded system.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]