Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

I am facing a problem on the system authenticate system. Our servers use the version 1.6 while clients use version 1.8, in the process of authenticate, we generate a key by "SHA1PRNG" with SecureRandom , while the following code: i.e.:

KeyGenerator keygen = KeyGenerator.getInstance("Blowfish"); 
SecureRandom foo = SecureRandom.getInstance("SHA1PRNG");
foo.setSeed("baa".getBytes());
keygen.init(foo);
The problem is that, we found that the key generated in clients is different from that in server. We have tired to print out all steps, and found that the problem is caused by the SecureRandom, i.e., after foo.setSeed("baa".getBytes()); if we call foo.nextBytes(), it will give different values.
Therefore, we would like to know whether there is any way to keep both side generate the same value? (Given that the version of Java in both clients and server can not be changed.) Or does any platform independent SecureRandom method in Java?
Background information: SERVER and CLIENT run in Unix.
I have a desktop running Java 1.8, and I have tested the followings:
Desktop Java 1.8 can encrypt and decrypt the key generated in CLIENT (Java 1.8)
CLIENT (Java 1.8) can not encrypt or decrypt the key generated in SERVER (Java 1.6) and verse versa.
CLIENT has installed Java 1.6 (only for testing) can not encrypt or decrypt the key generated in SERVER (Java 1.6). We guess it is because the /dev/random or /dev/urandom has been overwritten to Java 1.8 version. Therefore even the version of Java is the same, they have different behavior.
                @KarelG wrong - if you use the same seed then it is guranteed that the same values will be produced - Random is fully deterministic.
– Boris the Spider
                May 7, 2018 at 8:12
                @KarelG I don't understand what you are trying to say - please read the documentation linked in my answer. But suffice it to say, two instances of Random created with the same seed are requried to provide the same sequence.
– Boris the Spider
                May 7, 2018 at 8:22
                You do not need to share the instance between client and server @KarelG. You need to share the random seed.
– Boris the Spider
                May 7, 2018 at 8:24
                I took a look at the code here and the implementations for SecureRandom are, in fact, different between versions 1.6 and 1.8.
– Jenna Sloan
                May 7, 2018 at 8:41
  
Additionally, SecureRandom must produce non-deterministic output.
  Therefore any seed material passed to a SecureRandom object must be
  unpredictable, and all SecureRandom output sequences must be
  cryptographically strong, as described in RFC 1750: Randomness
  Recommendations for Security.
So, not only are you violating the requirements of SecureRandom by passing a predictable seed, but it is explicitly required that the output of SecureRandom is unpredictable.
In order to generate a predictable sequence of randomness, use Random:
  
If two instances of Random are created with the same seed, and the
  same sequence of method calls is made for each, they will generate and
  return identical sequences of numbers.
But note that: If you use the same seed every time, then the number will always be the same, so you must use the same initial seed, that is shared betwee client and server somehow. This initial seed need to be reset every time the server application is restarted.
The instance of Random must be shared between calls to the routine, otherwise the same single number will be generated each time:  
public static void main(final String[] args) {
    IntStream.range(1, 10)
            .map(i -> new Random(42).nextInt())
            .forEach(System.out::println);
Output:
-1170105035
-1170105035
-1170105035
-1170105035
-1170105035
-1170105035
-1170105035
-1170105035
-1170105035
                Thanks for your Answer, yes, you are right, we will set different seed every time and repeat generate several times to make it "less predictable". The Posted code just a part that we found different. our aims is to make both server and client generate the same unique code for communication. Would you mind to give any suggestion?
– shing_l
                May 7, 2018 at 8:29
                @shing_l I would still strongly recommend that you do not use your proposed solution. Without advasarial cryptanalysis and security analysis the solution is next to useless. Do not roll your own security.
– Boris the Spider
                May 7, 2018 at 8:32
                @BoristheSpider This answer doesn't actually offer an alternative solution, but instead only deprecates the coding methodology of the person asking the question.
– Jenna Sloan
                May 7, 2018 at 8:53
                @JennaSloan 1) it does offer an answer, use Random and share the seed. 2) often with crytography it is better to tell people why not to roll their own.
– Boris the Spider
                May 7, 2018 at 8:54
Don't invent your own key deviation functions. Use the functions invented for this.
You don't write what you use as input for your key deviation, but if it's a password you could use a PBE (Password based encryption) Key Spec - something like this: 
SecretKeyFactory factory = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA256");
KeySpec spec = new PBEKeySpec(password, salt, 65536, 256);
SecretKey tmp = factory.generateSecret(spec);
SecretKey secret = new SecretKeySpec(tmp.getEncoded(), "Blowfish");
                The OP is trying to generate a key for a symmetric cipher both client and server side using the same, predictable, mechanism - this is different to a KDF.
– Boris the Spider
                May 7, 2018 at 15:07
                @Ebbe M. Pedersen, Thanks for your suggestion, from your answer, I have take a look on this, stackoverflow.com/questions/992019/… , the OP there is doing something like our program. The SecretKey will be further used in Cipher in some other part. As I am using JDK 1.6, the factory should use "PBKDF2WithHmacSHA1", and the size of the key should be 128 rather than 256. However, I got another problem (java.security.InvalidKeyException) , it seems that we need to install something extra library (unlimited jurisdiction patch), right?
– shing_l
                May 8, 2018 at 4:30
                @Boris the Spider, Thanks for your explanation. Um...actually I am new in encryption, so I may explain wrongly on the meaning of predictable. Our system will do the same thing in both client and server side to encrypt and decrypt  some password. Just like jenna Sloan said, SecureRandom in 1.6 and 1.8 give different behavior. If the problem on SecureRandom solved, I can avoid large system changes.
– shing_l
                May 8, 2018 at 4:37
        
Thanks for contributing an answer to Stack Overflow!
Please be sure to answer the question. Provide details and share your research!
But avoid …
Asking for help, clarification, or responding to other answers.
Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.