[jira] [Commented] (HADOOP-10693) Implementation of AES-CTR CryptoCodec using JNI to OpenSSL

["Colin Patrick McCabe (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/HADOOP-10693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14042752#comment-14042752 ] 

Colin Patrick McCabe commented on HADOOP-10693:
-----------------------------------------------

Thanks for looking at this.

I find myself wishing we could avoid using OpenSSL here.  We've been relatively insulated from all the security advisories on that library up until this point.  Although I understand that the code path we're using here is just AES, and is not affected by Heartbleed or anything like that, it will mean more headaches for us if we have to monitor the OpenSSL vulnerability scene.  Especially for users who choose to bundle the library.

Is it possible to use something like this?  http://www.literatecode.com/aes256  This implementation is just two files, a .c and a .h, and doesn't require any libraries to be installed.  (I am just kicking around ideas here... maybe it isn't practical.)  But it sure would be way, way easier...

{code}
Support following options for build:
\-Dcrypto.prefix=
\-Dcrypto.lib=
\-Dcrypto.include=
\-Drequire.crypto
\-Dbundle.crypto
{code}

It's not really "crypto" we're locating with this, but the openssl library.  So the options should be named {{\-Dopenssl.prefix}}, etc.  Similar with a lot of the constants and other code options.

General formatting: we have an 80-column limit in Hadoop.

{code}
+  char * input_bytes = (*env)->GetDirectBufferAddress(env, input);
+  char * output_bytes = (*env)->GetDirectBufferAddress(env, output);
+  input_bytes = input_bytes + input_offset;
+  output_bytes = output_bytes + output_offset;
{code}

Formatting: should be {{char \*input_bytes}}.  Also, you need to check these against null, since they may not succeed on some JVMs or if a non-direct buffer was passed.

{code}
+  if (!(*dlsym_EVP_CipherUpdate)(context, (unsigned char *)output_bytes, &output_len, (unsigned char *)input_bytes, input_len)) {
{code}
You can just write {{dlsym_EVP_CipherUpdate(...)}}.  Same with all the other calls to function pointers.

> Implementation of AES-CTR CryptoCodec using JNI to OpenSSL
> ----------------------------------------------------------
>
>                 Key: HADOOP-10693
>                 URL: https://issues.apache.org/jira/browse/HADOOP-10693
>             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-10693.1.patch, HADOOP-10693.patch
>
>
> In HADOOP-10603, we have an implementation of AES-CTR CryptoCodec using Java JCE provider. 
> To get high performance, the configured JCE provider should utilize native code and AES-NI, but in JDK6,7 the Java embedded provider doesn't support it.
>  
> Considering not all hadoop user will use the provider like Diceros or able to get signed certificate from oracle to develop a custom provider, so this JIRA will have an implementation of AES-CTR CryptoCodec using JNI to OpenSSL directly.



--
This message was sent by Atlassian JIRA
(v6.2#6252)