Skip to content
New issue

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

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
spring-projects-issues opened this issue Apr 25, 2011 · 7 comments
Closed

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

spring-projects-issues opened this issue Apr 25, 2011 · 7 comments

Comments

@spring-projects-issues
Copy link

@spring-projects-issues spring-projects-issues commented Apr 25, 2011

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
@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Apr 25, 2011

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.

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Apr 25, 2011

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.

http://developer.android.com/reference/java/security/SecureRandom.html

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Apr 26, 2011

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.

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Apr 26, 2011

Roy Clarkson said:

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

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Apr 26, 2011

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.

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Apr 27, 2011

Roy Clarkson said:

Related to SEC-1731

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Apr 28, 2011

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant