Roy Clarkson (Migrated from SEC-1728) said:
Android does not support the "SUN" provider, which is the default in SecureRandomBytesKeyGenerator. Currently, there is no way to set a different provider. In order to use spring-security-crypto on Android, I have had to copy and rename the following classes, just so I can obtain a TextEncryptor that uses a different hard-coded provider.
Luke Taylor said:
I'm not sure why it has been coded with the SUN provider specified explicitly. This should probably be removed and the platform default used.
Roy Clarkson said:
I talked with Keith Donald about this, and it seems that it is best practice to specify the provider, since the algorithm implementations are not guaranteed to be compatible from provider to provider. That way you can at least be sure of which provider is being used. The Android reference also warns about this potential incompatibility.
What kind of compatibility do you mean? I'm not sure where compatibility is required when you're generating a random key. My guess is that they are just talking about compatibility in terms of reproducing the same stream from the same seed. Other algorithms, such as encryption, hashing etc, must be compatible by definition. Do you have a specific example where using the default provider would cause a problem.
Yes, I believe that is all it is referring to, that the same seed will not necessarily produce the same stream.
That doesn't seem to be something that should matter for random key generation. The Javadoc for SecureRandom actually says that it "must produce non-deterministic output", so as far as I can see it isn't intended for creating reproducible output. Certainly in this context it shouldn't matter.
Related to SEC-1731
I've removed the use of the SUN provider. If desired, users can configure their preferred providers through the local JRE setup to use a specific SecureRandom implementation (e.g. a hardware-based option). I've also removed the explicit use of SHA1PRNG which means that the native implementation (NativePRNG) will be used on platforms which support /dev/random. Internal seeding of the SecureRandom is now relied on, rather than the seeding code which was in place, which was using the key length as the number of seed bytes, which doesn't make sense. For example, the internal seeding code for sun.security.provider.SecureRandom uses 20 bytes (the size of the hash).