hello Casey, On Wednesday 25 January 2006 15:49, Casey Marshall wrote: > On Jan 24, 2006, at 1:18 AM, Raif S. Naffah wrote: > > 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... > >> > >> 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.
and later you said: > 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. fine. add a Factory method to the PRNG and use it to set an instance field in the using classes. > > 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. > > I think in that case the API is just flawed... i disagree. but this discussion is not about APIs. i was responding to your comment earlier about "...the JCE allow you to specify a SecureRandom when creating crypto objects..."; as a justification for not using PRNG. my responses were meant to show that this is not a convincing argument because the JCE allows you also _not_ to specify a source of randomness (e.g. AlgorithmParameterGenerator#init(int), KeyPairGenerator#initialize(int), Cipher#init(int,Key), etc...). in these cases the implementation has to use its own default. whether that default is a Singleton, a class field or an instance field that is the subject of discussion. > > 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.' using PRNG with a Factory method allows us to go later and change the returned concrete implementation without needing to go and edit every using class. the other alternative of using new SecureRandom leaves the applications at the mercy of a system administrator who can ultimately decide how to order the providers and potentially weaken the resulting material generated using a default 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'm saying both. last time i looked it was still being used and distributed in the GNU Crypto project. could it be that your previous comment is a tad exaggerated ;-) > And a global variable like that will still always be > a bottleneck for multithreaded applications. could be. in the absence of real metrics it's hard to gage the cost of these things. cheers; rsn
pgpPJxXznDjGu.pgp
Description: PGP signature
_______________________________________________ Classpath-patches mailing list [email protected] http://developer.classpath.org/mailman/listinfo/classpath-patches
