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