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....@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:brit...@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....@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:brit...@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-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
