On Jan 24, 2006, at 1:18 AM, Raif S. Naffah wrote:
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.
I don't think that approach makes much sense; in those cases the RNG
should be an instance variable of the object, and initialized to a
default one if no other RNG is specified.
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.
I think in that case the API is just flawed. GNU Crypto will become a
private API for Classpath once merged; so again, things don't have to
make sense outside of Classpath's usage of those classes.
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.
I agree. I also think we should take a deeper look at Classpath's
story w/r/t SecureRandom; SHA1PRNG isn't really secure at all, and we
aren't even making the attempt to read things like `/dev/random' for
seeds.
Currently the default implementation you get when you invoke `new
SecureRandom' is "the first one in the first provider," and that
generally means SHA1PRNG. I'd propose that we instead make the
default Fortuna for crypto-enabled Classpath, and SHA1PRNG for
export, and we make some effort to seed that instance with strong
system randomness, like by reading `/dev/u?random.'
...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.
I like making that default per-instance instead.
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'm saying both. And a global variable like that will still always be
a bottleneck for multithreaded applications.
...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.
OK, yes, a new instance doesn't make much sense IF that method is
called often; but I still doubt that anyone with a half-decent
garbage collector would care.
_______________________________________________
Classpath-patches mailing list
Classpath-patches@gnu.org
http://developer.classpath.org/mailman/listinfo/classpath-patches
