So, I am new to cryptography and I was learning about SecureRandom and all of the ways it calls implementations with or without providers.

When I looked up some sites for information, it says not to use providers because if the provider is outdated or not available in a system, then the application must be prepared to handle an exception.

However, many say use providers to outrun the risk of choosing a bad implementation like a blocking one.

In the Java docs, I read that when you specify a particular provider even if the framework has higher priority providers that offer the same implementation, it will only go to the mentioned provider to get the implementation. That does not sound appealing though.

So, should you user getInstance() with providers or not? Which is better?

  • 1
    This may be better suited for the cryptography it the stack overflow sites. – Daisetsu Oct 5 '18 at 20:34

This is a question inherently about trust of a cryptographic API, and is not really specific to SecureRandom. I will still formulate my answer around SecureRandom as it makes a good illustrative example.

Who do you trust more, the people who wrote the code of the API and documented it, or random comments on the web ? The developers made choices so you do not have to make them, because they have a better understanding of the stakes and issues than the common user of their API. For the sake of flexibility of their API, the developers allowed users to override their implementation decisions. You should do so only if you are sure to know better than them.

SecureRandom tries to use the best source available, usually one provided by the OS. Since you do not have the expertise to make a better choice (otherwise you would not have to ask your question), you should roll with the default, and handle exceptions appropriately (for example by refusing to provide an insecure service).

| improve this answer | |

Don't specify a provider. Definitely do not hardcode a provider. If it is not present then your application will simply not run.

The only reason to configure a provider is when the random values of a specific implementation by a provider offers properties that are not presented by the default ones. Even then, you should ask yourself if it that particular should not be used elsewhere as well, in which case you could put the random provider at the top of the list.

There are places where this is not possible: a notable issue could be the speed of the RNG. For instance, I could imagine that you want to use a smart card or random number generator of a TPM to generate long lived keys. That kind of random number generator is not something you want to use for each and every TLS session. Now this would be a good case to specify both the algorithm and the provider.

Even then, I would then input the choice using a (signed) configuration file rather than hardcoding the solution in source. Recompiling a solution just for the sake of a hardware update is generally not considered OK (especially not when it comes to Java / bytecode).

Note that software algorithms are deterministic and need to be seeded by the operating system. So you cannot avoid blocking if the systems random number generator blocks when providing the seed. So you may choose any kind of software provider, but you would still block the system until more entropy would become available.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy