--- Comment #10 from cvs-commit at developer dot classpath dot org
2006-04-12 16:39 ---
Subject: Bug 24481
CVSROOT:/cvsroot/classpath
Module name:classpath
Branch:
Changes by: Casey Marshall [EMAIL PROTECTED] 06/04/12 16:38:50
Modified files:
.
--- Comment #11 from csm at gnu dot org 2006-04-12 18:19 ---
Fixed for message digest-based PRNGs.
--
csm at gnu dot org changed:
What|Removed |Added
--- Comment #7 from csm at gnu dot org 2006-04-11 20:58 ---
I'm not sure I understand your situation. Are you doing:
SecureRandom r = new SecureRandom ();
for (...)
r.getBytes (...); // produces the same bytes each time
Or
for (...)
{
SecureRandom r = new
--- Comment #8 from david at jpackage dot org 2006-04-12 00:11 ---
The first case. There is only one instance of SecureRandom. The calls to
nextBytes() are on the same object.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24481
--- Comment #9 from csm at gnu dot org 2006-04-12 04:46 ---
Created an attachment (id=11246)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11246action=view)
SecureRandom setSeed test
I'm testing a patch for this.
Note that the attached test case will repeatedly output the same
--- Comment #5 from csm at gnu dot org 2006-04-11 04:21 ---
The original issue seems to be fixed; on gcj version `gcj (GCC) 4.2.0 20060410
(experimental)' I get this output from the `seed' testcase:
Byte difference in a seeded PRNG: 64
Seed data:
--- Comment #6 from david at jpackage dot org 2006-04-11 04:34 ---
I was saying something slightly different, since I did not test the program
across multiple runs. I did test nextBytes() within the same program run, and
this produced identical bytes with each successive call to
--- Comment #4 from david at jpackage dot org 2006-04-07 11:06 ---
I experienced a similar problem.
I created a new SecureRandom with
SecureRandom sr = new SecureRandom();
Then, multiple calls to
sr.nextBytes()
produced the same bytes each time.
--
--- Comment #3 from tromey at gcc dot gnu dot org 2005-10-24 18:47 ---
I'm still not clear on exactly why we see the same data here.
However, I suspect this can be fixed by adding 'seeded = true' to
SHA1PRNG.engineSetSeed().
--
tromey at gcc dot gnu dot org changed:
What
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-22 02:28 ---
java.security.SecureRandom is part of/comes from classpath on the mainline.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-22 02:36 ---
Confirmed on the mainline.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
11 matches
Mail list logo
