[CRYPTO] Feedback from ApacheCON Europe

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

[CRYPTO] Feedback from ApacheCON Europe

Benedikt Ritter-4
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
Reply | Threaded
Open this post in threaded view
|

RE: [CRYPTO] Feedback from ApacheCON Europe

Sun, Dapeng
Thank Benedikt for the minutes! And thank Xianda for the presentation.

-----Original Message-----
From: Benedikt Ritter [mailto:[hidden email]]
Sent: Saturday, November 19, 2016 7:49 PM
To: Commons Developers List <[hidden email]>
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: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [CRYPTO] Feedback from ApacheCON Europe

Benedikt Ritter-4
Hello Dapeng,

Sun, Dapeng <[hidden email]> 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:[hidden email]]
> Sent: Saturday, November 19, 2016 7:49 PM
> To: Commons Developers List <[hidden email]>
> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
Reply | Threaded
Open this post in threaded view
|

RE: [CRYPTO] Feedback from ApacheCON Europe

Sun, Dapeng
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:[hidden email]]
Sent: Wednesday, November 23, 2016 3:36 AM
To: Commons Developers List <[hidden email]>
Subject: Re: [CRYPTO] Feedback from ApacheCON Europe

Hello Dapeng,

Sun, Dapeng <[hidden email]> 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:[hidden email]]
> Sent: Saturday, November 19, 2016 7:49 PM
> To: Commons Developers List <[hidden email]>
> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: [CRYPTO] Feedback from ApacheCON Europe

Ke, Xianda
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:[hidden email]]
Sent: Thursday, November 24, 2016 10:27 AM
To: Commons Developers List <[hidden email]>
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:[hidden email]]
Sent: Wednesday, November 23, 2016 3:36 AM
To: Commons Developers List <[hidden email]>
Subject: Re: [CRYPTO] Feedback from ApacheCON Europe

Hello Dapeng,

Sun, Dapeng <[hidden email]> 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:[hidden email]]
> Sent: Saturday, November 19, 2016 7:49 PM
> To: Commons Developers List <[hidden email]>
> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [CRYPTO] Feedback from ApacheCON Europe

Matt Sicker
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 <[hidden email]> 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:[hidden email]]
> Sent: Thursday, November 24, 2016 10:27 AM
> To: Commons Developers List <[hidden email]>
> 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:[hidden email]]
> Sent: Wednesday, November 23, 2016 3:36 AM
> To: Commons Developers List <[hidden email]>
> Subject: Re: [CRYPTO] Feedback from ApacheCON Europe
>
> Hello Dapeng,
>
> Sun, Dapeng <[hidden email]> 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:[hidden email]]
> > Sent: Saturday, November 19, 2016 7:49 PM
> > To: Commons Developers List <[hidden email]>
> > 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>



--
Matt Sicker <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

RE: [CRYPTO] Feedback from ApacheCON Europe

Ke, Xianda
Hi Matt,

This technology named Intel® Secure Key was launched (May 2012) with the Intel® 3rd Generation Core™ processors (code-named Ivy Bridge).
Not only Xeon CPUS. For instance, i7-6700 supports Secure Key (https://ark.intel.com/products/88196/Intel-Core-i7-6700-Processor-8M-Cache-up-to-4_00-GHz).  You can check specifications in Intel's support page.

Regards,
Xianda

-----Original Message-----
From: Matt Sicker [mailto:[hidden email]]
Sent: Thursday, November 24, 2016 10:52 AM
To: Commons Developers List <[hidden email]>
Subject: Re: [CRYPTO] Feedback from ApacheCON Europe

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 <[hidden email]> 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:[hidden email]]
> Sent: Thursday, November 24, 2016 10:27 AM
> To: Commons Developers List <[hidden email]>
> 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:[hidden email]]
> Sent: Wednesday, November 23, 2016 3:36 AM
> To: Commons Developers List <[hidden email]>
> Subject: Re: [CRYPTO] Feedback from ApacheCON Europe
>
> Hello Dapeng,
>
> Sun, Dapeng <[hidden email]> 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:[hidden email]]
> > Sent: Saturday, November 19, 2016 7:49 PM
> > To: Commons Developers List <[hidden email]>
> > 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>



--
Matt Sicker <[hidden email]>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [CRYPTO] Feedback from ApacheCON Europe

Benedikt Ritter-4
In reply to this post by Ke, Xianda
Hello,

Ke, Xianda <[hidden email]> schrieb am Do., 24. Nov. 2016 um 03:49 Uhr:

> 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


It may be tedious for big data users. But it may also be useful for other
users :-) I've created CRYPTO-130 [1] so we can think about whether we want
to implement that some time.


>
>
> >> 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);
>
>
I think it would be good to have a FAQ page answering this commons
questions.

Benedikt

[1] https://issues.apache.org/jira/browse/CRYPTO-130


>
> Regards,
> Xianda
>
> -----Original Message-----
> From: Sun, Dapeng [mailto:[hidden email]]
> Sent: Thursday, November 24, 2016 10:27 AM
> To: Commons Developers List <[hidden email]>
> 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:[hidden email]]
> Sent: Wednesday, November 23, 2016 3:36 AM
> To: Commons Developers List <[hidden email]>
> Subject: Re: [CRYPTO] Feedback from ApacheCON Europe
>
> Hello Dapeng,
>
> Sun, Dapeng <[hidden email]> 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:[hidden email]]
> > Sent: Saturday, November 19, 2016 7:49 PM
> > To: Commons Developers List <[hidden email]>
> > 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>