hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yi Liu (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HADOOP-10734) Implementation of true secure random with high performance using hardware random number generator.
Date Fri, 04 Jul 2014 13:38:34 GMT

     [ https://issues.apache.org/jira/browse/HADOOP-10734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Yi Liu updated HADOOP-10734:

    Attachment: HADOOP-10734.1.patch

[~cmccabe], I update the patch for your comments.

If you want to do this in a follow-on JIRA, that's OK too.
Thanks, let do it together in HADOOP-10735

I think it's confusing that we have both org.apache.hadoop.crypto.random.SecureRandom andjava.security.SecureRandom.
Maybe a better name for this new class would be OpenSslSecureRandom or something like that,
to emphasize that it is using OpenSSL to get random bits.

Right, I change the name to {{OpensslSecureRandom}}

I think the comment is a bit misleading here. Openssl compiles on a lot of platforms that
don't have RDRAND. So all we really know here is that we're using openssl, not that we're
using RDRAND. I think it's appropriate to have a comment saying, "if you are using an Intel
chipset with RDRAND, the high-performance random number generator will be used", or something
like that. But it's platform specific and we may be compiling on another platform.

OK, I change the comment to _If using an Intel chipset with RDRAND, the high-performance hardware
random number generator will be used._

It's definitely difficult to test something which is returning true random numbers. It requires
a lot of mathematics. So I see why you did it this way. Just one comment... maybe I'm being
overly paranoid here, but can we loop until rand2 is not equal to rand1?
I agree it’s not good to test true random numbers in this way. I try to loop until rand2
is not equal to rand1, but then we need to {{Assert}} something, your suggestion is?

The stuff in /usr/include/bits is not public; it is an implementation detail that could change
at any time.
Agree, but maybe it’s not suitable to use {{gettid}} as a replacement, since from man page
The thread ID returned by this call is not the same thing as a POSIX thread ID (i.e., the
opaque value returned by pthread_self(3)).
I’m thinking we are not including {{/usr/include/bits/pthreadtypes.h}} directly, we are
using {{pthread.h}} which is public. If {{bits/pthreadtypes.h}} changed, there should be some
other place to define {{pthread_t}} and make sure existing programs using {{pthread}} still
Or you have other good way to replace {{pthread_self}}.

> Implementation of true secure random with high performance using hardware random number
> --------------------------------------------------------------------------------------------------
>                 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.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

View raw message