Bug 172101 - /dev/random and /dev/urandom NOT random
/dev/random and /dev/urandom NOT random
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: gcc (Show other bugs)
4
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-10-31 10:00 EST by bensmyth
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-11-07 03:14:20 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
GNU Compiler Collection 24642 None None None Never

  None (edit)
Description bensmyth 2005-10-31 10:00:14 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050524 Fedora/1.0.4-4 Firefox/1.0.4

Description of problem:
The following code should produce random numbers between 0..2^5-1 however it fails to do so on FC4.

import java.math.BigInteger;
import java.security.SecureRandom;
 
class RndTest {
   public static void main(String[] args) {
      SecureRandom rnd = new SecureRandom();
      for (int i = 0; i < 10; i++)
         System.out.print(new BigInteger(5,rnd) + " ");
   }
}


FC4 produces:
[ben@localhost src]$ java RndTest
0 31 12 21 21 16 8 24 15 20
[ben@localhost src]$ java RndTest
0 31 12 21 21 16 8 24 15 20
[ben@localhost src]$ java -Djava.security.egd=file:/dev/random RndTest
0 31 12 21 21 16 8 24 15 20

Alternative Linux system produces:
tinky-winky% java RndTest
15 8 18 20 30 6 12 31 31 17
tinky-winky% java RndTest
20 5 27 11 8 10 31 9 10 26

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. compile the included code
2. execute compiled code
3. execute compiled code


Actual Results:  steps 2 and 3 produce identical output

Expected Results:  steps 2 and 3 should produce random (non-identical [with high probability]) output.

Additional info:
Comment 1 bensmyth 2005-11-02 14:39:07 EST
Further information

[ben@localhost junit]$ java -version
java version "1.4.2"
gij (GNU libgcj) version 4.0.0 20050519 (Red Hat 4.0.0-8)
[ben@localhost src]$ java RndTest
0 31 12 21 21 16 8 24 15 20
[ben@localhost src]$ java RndTest
0 31 12 21 21 16 8 24 15 20
[ben@localhost src]$ java -Djava.security.egd=file:/dev/random RndTest
0 31 12 21 21 16 8 24 15 20


[brh@jupiter ~]$ java -version
java version "1.4.2"
gij (GNU libgcj) version 4.0.1 20050727 (Red Hat 4.0.1-5)

Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[brh@jupiter ~]$ java RndTest
0 31 12 21 21 16 8 24 15 20
[brh@jupiter ~]$ java RndTest
0 31 12 21 21 16 8 24 15 20 


See also: http://forums.java.sun.com/thread.jspa?messageID=3960085


This appears to be a bug with GNU libgcj as opposed to FC4. I have reported to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24642
Comment 2 Jakub Jelinek 2005-11-07 03:14:20 EST
And why are you reporting it here?  If it is tracked upstream, it is enough
to leave it tracked there and when it is resolved on gcc-4_0-branch, it will
be resolved in Fedora gcc soon after that as well.
Comment 3 bensmyth 2005-11-07 04:07:33 EST
Jakub,

I reported here first because I was unaware of where the bug was. Nor was I able
to get anyone to replicate the bug. Once the bug was replicated it became
apparent that it was an issue with libgcj and hence I reported to the correct place.

Note You need to log in before you can comment on or make changes to this bug.