The deployment of a JCE provider isn't that complicated in a containerized or otherwise automated (e.g., via Ansible) environment, but I'd imagine there are older clusters out there that have special snowflake configurations. As for the DRNG, is that only supported in Xeon CPUs? The article only mentions checking cpuid features with no indication as to when this instruction was added.
On 23 November 2016 at 20:48, Ke, Xianda <xianda...@intel.com> wrote: > 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 > -- Matt Sicker <boa...@gmail.com>
