commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ke, Xianda" <xianda...@intel.com>
Subject RE: [CRYPTO] Feedback from ApacheCON Europe
Date Thu, 24 Nov 2016 02:48:54 GMT
Hi Benedict,

>>1) Why does Commons Crypto implement it's own Crypto API instead of providing a JCE
provider?
Dapeng has answered the question. Here are some additional details
The deployment of JCE provider is tedious for big data user who owns thousands of nodes.
(a). copy jar to java-home,  (b). edit jre/lib/security/java.security properties file
Ref: https://docs.oracle.com/cd/E19830-01/819-4712/ablsc/index.html 

>> 2) Is it possible to stub in a custom secret generator? There where
Here is a sample for customized random generator.
props.setProperty(CryptoRandomFactory.CLASSES_KEY,   CryptoRandomFactory.RandomProvider.JAVA.getClassName());
CryptoRandom random = CryptoRandomFactory.getCryptoRandom(props);


Regards,
Xianda

-----Original Message-----
From: Sun, Dapeng [mailto:dapeng.sun@intel.com] 
Sent: Thursday, November 24, 2016 10:27 AM
To: Commons Developers List <dev@commons.apache.org>
Subject: RE: [CRYPTO] Feedback from ApacheCON Europe

Sure. Thank Benedikt for the reminder. Here is my thoughts:

>>1) Why does Commons Crypto implement it's own Crypto API instead of providing a JCE
provider?
>>If it is possible to write an adapter to JCE, I think this would be a  good improvement
for 1.1. 
>>If it is not possible for technical reasons, we should document it on the website.
At first, we built an adapter for JCE, it called diceros (https://github.com/intel-hadoop/diceros),
but we found it is not easy to deploy the library to a cluster with many nodes (need to modify
JDK profile or update source code with special code). For these cases, Crypto would be the
better solution.

>> 2) Is it possible to stub in a custom secret generator? There where 
>> concerns in the audience with regards to the hardware secret 
>> generator build into the Intel chips, because it is not clear what is 
>> happening inside that chips.
Yes, the secret generator is also designed as an interface, we can custom secret generator.
About what is happening inside the chips, I think this article would be helpful: 
https://software.intel.com/en-us/articles/intel-digital-random-number-generator-drng-software-implementation-guide



-----Original Message-----
From: Benedikt Ritter [mailto:britter@apache.org]
Sent: Wednesday, November 23, 2016 3:36 AM
To: Commons Developers List <dev@commons.apache.org>
Subject: Re: [CRYPTO] Feedback from ApacheCON Europe

Hello Dapeng,

Sun, Dapeng <dapeng.sun@intel.com> schrieb am Mo., 21. Nov. 2016 um
03:12 Uhr:

> Thank Benedikt for the minutes! And thank Xianda for the presentation.
>

Can you share your thoughts regarding the comments 1) & 2) we got from the audience? (see
below)

Thank you!
Benedikt


>
> -----Original Message-----
> From: Benedikt Ritter [mailto:britter@apache.org]
> Sent: Saturday, November 19, 2016 7:49 PM
> To: Commons Developers List <dev@commons.apache.org>
> Subject: [CRYPTO] Feedback from ApacheCON Europe
>
> Hi,
>
> Xianda Ke held a nice presentation about Commons Crypto yesterday at 
> ApacheCON Europe in Seville. Kudos to Xianda Ke and Dapeng Sun for 
> preparing the presentation and making the long trip to Europe.
>
> Here are the comments we got from the audience:
>
> 1) Why does Commons Crypto implement it's own Crypto API instead of 
> providing a JCE provider?
> If it is possible to write an adapter to JCE, I think this would be a 
> good improvement for 1.1. If it is not possible for technical reasons, 
> we should document it on the website.
>
> 2) Is it possible to stub in a custom secret generator? There where 
> concerns in the audience with regards to the hardware secret generator 
> build into the Intel chips, because it is not clear what is happening 
> inside that chips.
> Can we extend the API in a why so that users can provide their own 
> secret generator? Does this even make sense or will that degrade the 
> performance of Crypto?
>
> Regards,
> Benedikt
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Mime
View raw message