Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

SEC-1728: Add support for alternate SecureRandom providers #1965

spring-issuemaster opened this Issue Apr 25, 2011 · 7 comments


None yet
1 participant

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.

  • org.springframework.security.crypto.encrypt.Encryptors
  • org.springframework.security.crypto.keygen.KeyGenerators
  • org.springframework.security.crypto.keygen.SecureRandomBytesKeyGenerator

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.


Luke Taylor said:

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.

Roy Clarkson said:

Yes, I believe that is all it is referring to, that the same seed will not necessarily produce the same stream.

Luke Taylor said:

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.

Roy Clarkson said:

Related to SEC-1731

Luke Taylor said:

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

@spring-issuemaster spring-issuemaster added this to the 3.1.0.RC2 milestone Feb 5, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment