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

[Casey Marshall]

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:
> > > >
> > > >    <http://metastatic.org/source/gnu-crypto-jessie-2.patch.txt>
> > > >    <http://metastatic.org/source/gnu-crypto-jessie-2.zip>
>
> 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.

Thanks.