Spring Security
  1. Spring Security
  2. SEC-1728

Add support for alternate SecureRandom providers

    Details

    • Type: Story Story
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.1.0.RC1
    • Fix Version/s: 3.1.0.RC2
    • Component/s: Crypto
    • Labels:
    • Environment:
      Android

      Description

      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

        Activity

        Hide
        Luke Taylor added a comment -

        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.

        Show
        Luke Taylor added a comment - 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.
        Hide
        Roy Clarkson added a comment -

        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

        Show
        Roy Clarkson added a comment - 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
        Hide
        Luke Taylor added a comment -

        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.

        Show
        Luke Taylor added a comment - 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.
        Hide
        Roy Clarkson added a comment -

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

        Show
        Roy Clarkson added a comment - Yes, I believe that is all it is referring to, that the same seed will not necessarily produce the same stream.
        Hide
        Luke Taylor added a comment - - edited

        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.

        Show
        Luke Taylor added a comment - - edited 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.
        Hide
        Roy Clarkson added a comment -

        Related to SEC-1731

        Show
        Roy Clarkson added a comment - Related to SEC-1731
        Hide
        Luke Taylor added a comment -

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

        Show
        Luke Taylor added a comment - 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).

          People

          • Assignee:
            Luke Taylor
            Reporter:
            Roy Clarkson
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: