What is the difference between functions nextXXX() - such as like nextInt(), nextFloat() and nextBytes() - and generateSeed(int numBytes): byte[] in the SecureRandom class of Java?
In what way does "the seed generation algorithm" in generateSeed differ from the secure random generator itself?
generateSeed() does not use any bytes generated by the random number generator. Instead, it is just a pass through to the entropy source that the SecureRandom implementation uses to seed itself when and if it is seeding itself.
So for instance calling the following code on an Oracle provided Java SE:
// initSeed is just zero valued bytes
byte[] initSeed = new byte[16];
SecureRandom secureRandom = SecureRandom.getInstance("SHA1PRNG");
secureRandom.setSeed(initSeed);
byte[] seed = secureRandom.generateSeed(16);
byte[] data = new byte[16];
secureRandom.nextBytes(data);
System.out.printf("Seed: %s%n", Hex.toHexString(seed));
System.out.printf("Data: %s%n", Hex.toHexString(data));
Will actually give back different values for seed, and always the same value for data. In other words, the generateSeed uses the operating system to ask for 16 bytes of entropy, while the random number generator is only seeded with the initSeed and thus will always generate the same stream of pseudo random numbers.
Warning: this is just to illustrate the point; you should not rely on any SecureRandom instance to return anything but random bytes. The behavior with regards to setSeed differs per implementation. The Oracle "SHA1PRNG" provider uses it as the only seed, others may choose to mix it into the state of the PRNG (for instance later Android implementations will always generate random data).
Random number functions depend on an initial value from which they generate a sequence of random numbers (read up on PRNG - Pseudo Random Number Generation). The next functions will return the next number generated from that initial value (the seed). generateSeed() will generate a new initial value for a PRNG to use.
In fact, nextXYZ() and generateSeed() do the exactly same thing, most often 😏
SecureRandom.nextBytes() and SecureRandom.generateSeed() actually are just thin wrappers that forward the call to SecureRandomSpi.engineGenerateSeed() and SecureRandomSpi.engineNextBytes(), respectively, which contain the actual implementation.
The concrete implementation of SecureRandomSpi depends on the selected algorithm, of course! However, for the default SecureRandom algorithm on the Windows platform (i.e. "Windows-PRNG"), we can see from the source code that engineNextBytes() and engineGenerateSeed() do the exactly same thing: They both call a native method named PRNG.generateSeed(), which is a C++ function that ends up calling the Win32 API function CryptGenRandom() from the OS 😲
See here for details:
The implementation of the "NativePRNG" algorithm, which is the default algorithm on Linux/Unix and MacOS, is a bit more convoluted. But, essentially, engineNextBytes() and engineGenerateSeed() once again both end up in the same method – which is RandomIO.readFully(). That method simply reads the "random" bytes from an InputStream, which has been associated with /dev/[u]random, i.e. the kernel random number source.
See here for details:
All of the other [Secure]Random.nextXYZ() methods, such as nextInt(), nextLong() or nextDouble(), call an internal method named next(), which provides the request number of random bits. And, not much surprising, the next() method ends up calling nextBytes() – and therefor, in case of SecureRandom, invokes SecureRandomSpi.engineNextBytes() 😂
© 2022 - 2024 — McMap. All rights reserved.