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.
_______________________________________________
Classpath-patches mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/classpath-patches
