[ 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)