[
https://issues.apache.org/jira/browse/HADOOP-10734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14056877#comment-14056877
]
Colin Patrick McCabe commented on HADOOP-10734:
-----------------------------------------------
Hi Yi,
I wanted to present an alternate implementation here. This implementation just
reads from {{/dev/urandom}}. This has a few advantages:
* does not require JNI or openssl to be installed
* mixes in additional randomness sources in addition to RDRAND (on Intel
machines with Linux, RDRAND will be included, of course)
* a lot shorter
Because it reads a large chunk (8k) at a time from {{/dev/urandom}}, the
overhead of the read system call should be pretty low. Take a look and see if
this makes sense to you. I'm curious what the performance difference is...
maybe if the openssl method is a lot faster, we should still go with that. But
I wanted us to consider this.
> 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.1.patch, HADOOP-10734.2.patch,
> HADOOP-10734.3.patch, 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)
