[
https://issues.apache.org/jira/browse/HADOOP-10734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14050559#comment-14050559
]
Andrew Wang commented on HADOOP-10734:
--------------------------------------
I have only a modest background in this area, but my understanding is that the
Linux random subsystem is carefully designed to mix in different entropy
sources. This prevents a single bad entropy source from leading to poor
entropy. [1] has some info from Ted Ts'o, who's the maintainer of the random
subsystem; he explicitly mentions the importance of using a mixed source of
randomness for things like encryption keys.
How bad is the perf difference going to be for /dev/urandom with rdrand mixed
in vs direct rdrand? Is it going to matter for our workloads?
[1] https://news.ycombinator.com/item?id=6038473
> Implementation of true secure random with high performance using hardware
> random number generator.
> --------------------------------------------------------------------------------------------------
>
> Key: HADOOP-10734
> URL: https://issues.apache.org/jira/browse/HADOOP-10734
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: security
> Affects Versions: fs-encryption (HADOOP-10150 and HDFS-6134)
> Reporter: Yi Liu
> Assignee: Yi Liu
> Fix For: fs-encryption (HADOOP-10150 and HDFS-6134)
>
> Attachments: HADOOP-10734.patch
>
>
> This JIRA is to implement Secure random using JNI to OpenSSL, and
> implementation should be thread-safe.
> Utilize RdRand to return random numbers from hardware random number
> generator. It's TRNG(True Random Number generators) having much higher
> performance than {{java.security.SecureRandom}}.
> https://wiki.openssl.org/index.php/Random_Numbers
> http://en.wikipedia.org/wiki/RdRand
> https://software.intel.com/en-us/articles/performance-impact-of-intel-secure-key-on-openssl
--
This message was sent by Atlassian JIRA
(v6.2#6252)
