7

I am wondering if I can instantiate the javax.crypto.KeyGenerator only once and then use this instance in a multithread environment.

Its JavaDoc documentation does not say anything about its thread-safeness. Or it will be better to use a ThreadLocal<KeyGenerator> approach?

UPDATE: A related question is Is SecureRandom thread safe? While the JavaDoc doesn't state that class is thread safe, the community still found the decision that it is thread-safe what is quite important from the practical point of view. I would like to know the same for the KeyProvider.

Community
  • 1
  • 1
Andremoniy
  • 34,031
  • 20
  • 135
  • 241
  • https://stackoverflow.com/questions/30688609/is-java-security-module-keygenerator-thread-safe-if-not-then-how-to-fix-it – assylias Dec 06 '17 at 16:09
  • @assylias I saw that question. Besides the fact that it doesn't provide any useful answer, the question itself is very vague and is related more to that specific problem with particular scala code. – Andremoniy Dec 06 '17 at 16:10
  • 1
    I think you are misreading the SecureRandom answer. If the documentation does not say it is thread safe then it is a bug to assume it is. – President James K. Polk Dec 06 '17 at 18:19
  • @JamesKPolk The bug is that it is not marked as it ThreadSafe, while in fact it is (if we are talking about SecureRandom) – Andremoniy Dec 06 '17 at 18:20
  • @JamesKPolk: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6498354 – Andremoniy Dec 06 '17 at 18:21
  • 3
    There's no reason to assume that's a bug. The fact that a given implementation is thread-safe is not a guarantee that the next version will be. The only guarantees are what is in the Javadocs. – President James K. Polk Dec 06 '17 at 18:26
  • @JamesKPolk I agree with you, and I would rather consider it as non-thread-safe. But community says that in fact it *is* thread safe. – Andremoniy Dec 06 '17 at 18:26
  • 1
    The community does not say that, one user, @erickson, says that (wrongly). The other users note that the *current implementation* is thread-safe. As I said, it is a bug to rely on the such implementation-specific behaviors. – President James K. Polk Dec 06 '17 at 18:30
  • @JamesKPolk I buy your point of view. It can be one of the accepted answers. – Andremoniy Dec 06 '17 at 18:33
  • 3
    What 'the community' says is irrelevant. The only relevant source is the official documentation. – user207421 Dec 06 '17 at 18:36
  • @EJP I agree with you on 100%. That's what is said in Joshua Bloch's "Effective Java" as far as I remember. – Andremoniy Dec 06 '17 at 18:37

1 Answers1

7

Unless the documentation explicitly guarantees thread-safety then treat anything as if it is not thread-safe.

You're right this philosophy is hardly helpful with the scarcity of thread-safety documentation... But without the documentation guaranteeing thread-safety then you simply can't assume something is or will continue to be thread-safe.

Here's some research into the actual implementation of KeyGenerator and why we can't assume that it's thread safe

I found the source and at first glance it would seem like the current implementation is thread safe. However, even if we were to assume this implementation were to never change, it makes calls to Security Providers which could be any implementation of their own and also have no guarantee of being thread-safe since the documentation says nothing about it.

Summary of the source:

Calls to generateKey() use a "Key Generator Service Provider" calling KeyGeneratorSpi.engineGenerateKey() (which could be thread-unsafe) to generate the SecretKey.

If you constructed the KeyGenerator with a specific provider then it will use that specific provider to generate the key.

If you did not construct KeyGenerator with a specific provider then nextSpi() will iterate (thread-safely) through the JVMs list of available providers and try to generate the key until one works or you run out of providers..

The main point is documentation... If the documentation says nothing about thread-safety then any current implementer or an update to the current implementation might not be thread safe.

So you simply cannot assume or depend on any thread safety from KeyGenerator.

xtratic
  • 4,600
  • 2
  • 14
  • 32
  • Thanks, I know about this approach. But it doesn't work in practical purposes. Look at this question: https://stackoverflow.com/questions/1461568/is-securerandom-thread-safe – Andremoniy Dec 06 '17 at 16:09
  • @Andremoniy Updated my response. – xtratic Dec 06 '17 at 16:19
  • Your answer would be perfect and definitely accepted if you provide particular peace of its source code which is **not** thread safe. That would be an evidence of its non-thread-safety. – Andremoniy Dec 06 '17 at 16:23
  • @Andremoniy working on it, unfortunately byte code is all I have to work with. – xtratic Dec 06 '17 at 16:33
  • That was an issue. What am I looking for is an evidence of such thread-unsafety. Unfortunately your current answer doesn't bring any value, as this kind of approach (I mean what you suggest - if it is not marked as thread-safe consider it as non-thread-safe) is known for me and everyone. – Andremoniy Dec 06 '17 at 16:35
  • I've removed my downvote in appreciation of your efforts. But it is still not convincing for me, I am sorry. Let's wait for another reactions. – Andremoniy Dec 06 '17 at 17:57
  • @Andremoniy I looked further into it, it's still pretty iffy. – xtratic Dec 06 '17 at 17:58
  • In my opinion, the answer in that thread about SecureRandom is incorrect, and this answer is correct. – President James K. Polk Dec 06 '17 at 18:12
  • 3
    +1 for a thorough answer, but you did too much work! Your original shorter answer was correct. The fact that current implementations may or may not be thread-safe is mostly irrelevant. The implementation can change tomorrow and the only behavior guarantees are those given in the Javadocs. – President James K. Polk Dec 06 '17 at 18:23
  • 1
    @JamesKPolk Exactly, that's an issue especially in regards to `KeyGeneratorSpi` which could really be anything... – xtratic Dec 06 '17 at 18:27
  • 3
    @Andremoniy The whole point of this correct answer is that you need evidence of thread *safety*, and in the *documentation,* and that you should not assume it unless you find it. – user207421 Dec 06 '17 at 18:33
  • If the very @EJP accepts the answer, I have no other way than accept it as well. – Andremoniy Dec 06 '17 at 18:34
  • @EJP Yep, that is exactly the point of this answer. The documentation for `KeyGeneratorSpi.engineGenerateKey()` has no thread-safety requirements therefore the thread-safety of `KeyGenerator`s methods is really a moot point. – xtratic Dec 06 '17 at 18:42