[Bug java/24481] New: SecureRandom.setSeed has no impact

[Bug java/24481] New: SecureRandom.setSeed has no impact

[jrandom-gcc at i2p dot net]

java.security.SecureRandom in GCJ 4.0.2 has no impact, so SecureRandom always
uses the same weak seed.  This has obvious security issues, though they'd take
a targetted attack to mount (e.g. force a JVM restart so the SecureRandom
reverts to the default seed - "new java.util.Random(0l).nextBytes(new
byte[20])", per gnu.java.security.provider.SHA1PRNG.ensureIsSeeded()).

jrandom@betty ~/dev/i2p/native $ gcj -o seed --main=seed seed.java
jrandom@betty ~/dev/i2p/native $ ./seed
Byte difference in a seeded PRNG: 0
Seed data:
8bc7ec2ec7c4f87a13ec6120616ead831baeaf40dfd0804c534145ddbd12c580926578f8e0fea3b8b69287e26841a91cfca9a63fa95e453494f495ff14c82
jrandom@betty ~/dev/i2p/native $ cat seed.java
import java.security.SecureRandom;

public class seed {
  public static void main(String args[]) {
    SecureRandom r = new SecureRandom();
    byte unseededBuf[] = new byte[64];
    r.nextBytes(unseededBuf);

    r = new SecureRandom();
    byte seededBuf[] = new byte[64];
    r.setSeed(unseededBuf);
    r.nextBytes(seededBuf);

    int diffs = 0;
    for (int i = 0; i < 64; i++) {
      if (seededBuf[i] != unseededBuf[i])
        diffs++;
    }
    System.out.println("Byte difference in a seeded PRNG: " + diffs);
    System.out.print("Seed data: ");
    for (int i = 0; i < 64; i++)
      System.out.print(Integer.toHexString((int)(unseededBuf[i]&0xFF)));
    System.out.println();
  }
}

The secureRandom.getProvider().toString() returns
"gnu.java.security.provider.Gnu: name=GNU version=1.0", which in turn uses the
SHA1PRNG (in the 4.0.2 release, at least).  The odd part is that the provider
should be taking into account the seed - engineSetSeed *looks* right, and
java.security.SecureRandom.java's setSeed just calls the spi.engineSetSeed, so
I'm not sure whats going on here.

=jr


-- 
           Summary: SecureRandom.setSeed has no impact
           Product: gcc
           Version: 4.0.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: java
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: jrandom-gcc at i2p dot net


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24481

[Bug classpath/24481] SecureRandom.setSeed has no impact

[pinskia at gcc dot gnu dot org]

------- 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
----------------------------------------------------------------------------
                 CC|                            |bug-classpath at gnu dot org
          Component|libgcj                      |classpath
            Product|gcc                         |classpath
            Version|4.0.2                       |0.15


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24481

[Bug classpath/24481] SecureRandom.setSeed has no impact

[pinskia at gcc dot gnu dot org]

------- 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
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2005-10-22 02:36:21
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24481

[Bug classpath/24481] SecureRandom.setSeed has no impact

[tromey at gcc dot gnu dot org]

------- 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    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24481

[Bug classpath/24481] SecureRandom.setSeed has no impact

[david at jpackage dot org]

------- 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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24481

[Bug classpath/24481] SecureRandom.setSeed has no impact

[csm at gnu dot org]

------- 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: 9c1185a5c5e9fc5461288977ee8f548b2258d3138bbc57e4cbe8b6a1d2c999ef6253e0a6e58196ae643db8559e6ba7c97214bd66197b97184d68e3b0654b

David, are you saying that if you have a program like:

> import java.security.SecureRandom;
> 
> class sr
> {
>   public static void main (String[] argv) throws Throwable
>   {
>     SecureRandom sr = new SecureRandom ();
>     byte[] b = new byte[64];
>     sr.nextBytes (b);
>     for (int i = 0; i < b.length; i++)
>       {
>         System.out.print (b[i]);
>         System.out.print (' ');
>       }
>     System.out.println ();
>   }
> }

...that you get the same output every time?

If so, this is because our default SecureRandom isn't seeded when created.
Ideally, we would try to use `/dev/random,' or some timing data to get a random
seed.


-- 

csm at gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |david at jpackage dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24481

[Bug classpath/24481] SecureRandom.setSeed has no impact

[david at jpackage dot org]

------- 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 nextBytes().

Checking the javadocs, I find:

``Note that this instance of SecureRandom has not been seeded... [but] [i]f a
call is not made to setSeed, the first call to the nextBytes method will force
the SecureRandom object to seed itself.''

Note that even though `new SecureRandom()' does not seed itself, any attempt to
extract randomness will cause it to seed itself first before returning any
bytes, so I believe the GNU implementation to be incorrect.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24481

[Bug classpath/24481] SecureRandom.setSeed has no impact

[csm at gnu dot org]

------- 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 SecureRandom ();
      r.getBytes (...); // produces the same bytes each time
    }

I'd expect the second case to produce the same bytes on each iteration, but not
the first case.

Also, see bug 27111, which tracks the issue of SecureRandom instances not being
seeded properly.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24481

[Bug classpath/24481] SecureRandom.setSeed has no impact

[david at jpackage dot org]

------- 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

[Bug classpath/24481] SecureRandom.setSeed has no impact

[csm at gnu dot org]

------- 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=11246&action=view)
SecureRandom setSeed test

I'm testing a patch for this.

Note that the attached test case will repeatedly output the same bytes.
However, if you change the byte array size to 20 or more, the output is
different per call to `nextBytes'. SHA1 is 20 bytes long, so I suspect that we
were keeping a buffer in our secure random the size of the hash function, and
when we add a seed to it, we are resetting the index into this buffer.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24481

[Bug classpath/24481] SecureRandom.setSeed has no impact

[cvs-commit at developer dot classpath dot org]

------- 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 <rsdio@savannah.gnu.org> 06/04/12 16:38:50

Modified files:
        .              : ChangeLog 
        gnu/java/security/jce/prng: SecureRandomAdapter.java 
        gnu/java/security/prng: MDGenerator.java 

Log message:
        2006-04-12  Casey Marshall  <csm@gnu.org>

        Fixes PR classpath/24481.
        * gnu/java/security/jce/prng/SecureRandomAdapter.java (<init>):
        initialize the adaptee.
        (setSeed): call `addRandomBytes;' don't re-initialize the adaptee.
        * gnu/java/security/prng/MDGenerator.java (addRandomByte,
        addRandomBytes): new methods.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/ChangeLog.diff?tr1=1.7086&tr2=1.7087&r1=text&r2=text
http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/gnu/java/security/jce/prng/SecureRandomAdapter.java.diff?tr1=1.1&tr2=1.2&r1=text&r2=text
http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/gnu/java/security/prng/MDGenerator.java.diff?tr1=1.2&tr2=1.3&r1=text&r2=text


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24481

[Bug classpath/24481] SecureRandom.setSeed has no impact

[csm at gnu dot org]

------- 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
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |0.91


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24481