classpath-patches
[Top][All Lists]
Advanced

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

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


From: Raif S. Naffah
Subject: [cp-patches] Re: RFC: GNU Crypto and Jessie (again)
Date: Tue, 24 Jan 2006 20:18:17 +1100
User-agent: KMail/1.9.1

hello Casey,

On Tuesday 24 January 2006 06:28, Casey Marshall wrote:
> On Jan 23, 2006, at 9:34 AM, Raif S. Naffah wrote:
> > ...
> > 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.

in the classes i looked at; i.e. DSSKeyPairGenerator, FIPS186, 
RSAKeyPairGenerator, PRNG is _only_ used when the caller has not 
specified a source of randomness.  in other classes, it is used when 
the specifications does not mandate, or the API does not allow 
specifying a source randomness; e.g. RSA, EME_PKCS1_V1_5.  if there are 
specific instances where the PRNG object is used when the caller has 
set her own source of randomness then it's a bug and we can/should fix 
it.


> ...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.

indeed, and that's the intent of that object; i.e. to be used when the 
user has not specified a preferred source of randomness.


> And sharing random bits is 
> unwise.

if you're saying that the implementation of the PRNG object is buggy, we 
can fix it.  if you're saying that it is insecure, we can discuss how 
it so.  what are you really saying?


> ...I
> seriously doubt that anyone would notice or care that we use one
> additional, short-lived object...

look at the DSSKeyPairGenerator and the FIPS186 classes, a new 
SecureRandom object is created _every_ time the nextRandomBytes() 
method is called.  if i haven't convinced you so far, at least, make it 
a class field.



cheers;
rsn

Attachment: pgpY6XUIZzKYF.pgp
Description: PGP signature


reply via email to

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