[
https://issues.apache.org/jira/browse/HADOOP-10693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14043948#comment-14043948
]
Colin Patrick McCabe commented on HADOOP-10693:
-----------------------------------------------
[~tucu00], [~apurtell]: Yeah, you are right. It is nice to use the
CPU-optimized implementation in openssl, and it does avoid some of the export
issues.
{code}
+ conf.set(HADOOP_SECURITY_CRYPTO_CODEC_CLASS_KEY,
+ OpenSSLAESCTRCryptoCodec.class.getName());
{code}
Tucu is right here... rather than configuring a single codec class, why don't
we make this configuration contain a comma-separated list of codecs to try?
That way it would be pretty simple to configure the system to use openssl with
fallback to JCE, etc. We would simply keep trying entries in the list until
one was available.
{code}
+ if (!dlsym_EVP_CipherUpdate(context, (unsigned char *)output_bytes, \
+ &output_len, (unsigned char *)input_bytes, input_len)) {
{code}
These casts could be avoided if you just made the type of {{output_bytes}} and
{{input_bytes}} unsigned.
{code}
+ jbyte *jKey = (*env)->GetByteArrayElements(env, key, NULL);
+ jbyte *jIv = (*env)->GetByteArrayElements(env, iv, NULL);
+
+ dlsym_EVP_CipherInit_ex(context, getEvpCipher(alg, jKeyLen), NULL, \
+ (unsigned char *)jKey, (unsigned char *)jIv, mode == ENCRYPT_MODE);
+
+ (*env)->ReleaseByteArrayElements(env, key, jKey, 0);
+ (*env)->ReleaseByteArrayElements(env, iv, jIv, 0);
{code}
We need to do error checking here in case the {{GetByteArrayElements}} calls
fail.
{code}
+
+#if defined HADOOP_OPENSSL_LIBRARY
+
{code}
Rather than having stuff like this, let's just change the CMakeLists.txt file
to not include this file unless openssl is found. #ifdefing out a whole file
is just weird, and has led to bugs in the past.
Are you familiar with {{checknative}}? It prints out a bunch of information
about the native libraries which are available. For example, this is what it
prints for me:
{code}
$ hadoop checknative
Native library checking:
hadoop: true /h/lib/native/libhadoop.so.1.0.0
zlib: true /lib64/libz.so.1
snappy: true /usr/local/lib64/libsnappy.so.1
lz4: true revision:99
bzip2: true /usr/lib64/libbz2.so.1
{code}
It would be great to include {{openssl.so}} in here as well.
What's the best way to test this JNI code? Perhaps running {{TestCryptoCodec}}
with the correct configuration? Perhaps we ought to have a subclass of
{{TestCryptoCodec}} that sets this configuration and then runs the parent
class. If we don't have any unit test coverage on Jenkins, then I am afraid
this might bitrot.
Very encouraging progress so far, looking forward to seeing this get in.
> 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.2.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)
