Janusgraph: Fix insecure randomness
Fortify - Use SecureRandom instead of Random
amcp
All 3 comments
I'm all for using SecureRandom vs. Random, but my understanding is that typically, more secure random generators require more entropy, and when you run out of such entropy sources, the consumers slow down while they wait for additional entropy. Are the uses of randomness really security-sensitive in JanusGraph? Should we be willing to pay a performance penalty by using more secure random generators?
Alternatively, users will need to use a workaround to avoid the slowdown, which will become a usability problem, which will impact user adoption: (a) user forgets / misses the docs about the workaround, (b) user finds the JanusGraph is too slow (due to the use of SecureRandom), (c) user never bothers asking on the mailing lists why it's slow, and instead chooses to evaluate something else.
Here are some references:
- Stack Overflow: How to solve performance problem with Java SecureRandom?
- The dangers of
java.security.SecureRandom - Stack Overflow: Slow service response Times : Java
SecureRandom&/dev/random
In particular, it appears that /dev/random used as source of entropy blocks when there's not enough entropy data, thus causing the slowdown. Several sources suggest using /dev/urandom instead:
- Oracle/BEA: Avoiding JVM Delays Caused by Random Number Generation
- Stack Overflow: answer to one of the questions above
- Myths about
/dev/urandom
That said, as per above, requiring users to make a manual workaround will affect user adoption, so this must be done automatically for them, without any extra manual steps on their part.
mbrukman
on 21 Jan 2017
@amcp The explanation provided here by @mbrukman seems like a reasonable justification for these findings. It doesn't seem like we need the stronger randomness in these usages so it's probably not worth the extra performance cost. What do you think?
sjudeng
on 19 Aug 2017
Not worth it.
amcp
on 19 Aug 2017
Related issues
bionicles
路
4Comments
code5hot
路
4Comments
lazharichir
路
5Comments
lmcrazy
路
5Comments
amyth
路
4Comments
Most helpful comment
I'm all for using
SecureRandomvs.Random, but my understanding is that typically, more secure random generators require more entropy, and when you run out of such entropy sources, the consumers slow down while they wait for additional entropy. Are the uses of randomness really security-sensitive in JanusGraph? Should we be willing to pay a performance penalty by using more secure random generators?Alternatively, users will need to use a workaround to avoid the slowdown, which will become a usability problem, which will impact user adoption: (a) user forgets / misses the docs about the workaround, (b) user finds the JanusGraph is too slow (due to the use of
SecureRandom), (c) user never bothers asking on the mailing lists why it's slow, and instead chooses to evaluate something else.Here are some references:
java.security.SecureRandomSecureRandom&/dev/randomIn particular, it appears that
/dev/randomused as source of entropy blocks when there's not enough entropy data, thus causing the slowdown. Several sources suggest using/dev/urandominstead:/dev/urandomThat said, as per above, requiring users to make a manual workaround will affect user adoption, so this must be done automatically for them, without any extra manual steps on their part.