You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Giorgio Zoppi <gi...@gmail.com> on 2016/05/13 19:48:16 UTC
[CRYPTO] High level API for Common crypto
Dear all,
I have been really happy to see an effort for a crypto api in apache.org,
so i decided to provide for comment a design of an high level. Many
cryptosystem around the world are using hardware security modules so the
idea to integrate the that in an opensource api is pretty cool. In the
attached image you may see the first raw design. I will explain the
rational:
1. CryptoOperation: this is the interface that you want to extend for your
own operation. That they may be simple or composite. In the cryptoworld you
may want to execute and AES and than from that cipherered you may want do
something else, an xor with some padding for example. So it is nice to
provide composite for this reason. Or another example Create a key pair
with NIST 192 and than sign some data.
2. SimpleCryptoOperation: AESCiphering, ECPublicKeyCrreating. A single shot
of execution.
3. CompoundCryptoOperation: a composite (a la compositte design pattern) of
single operation. The executor of the operation will get the output of the
first operation as input of the second operation.
4. CryptoProcessor: An executor of cryptographic operation (simple or
composite) potentially may be local or remote. The CryptoProcessor is the
interface.
5. OpenSSLCryptoProcessor: this the backend of the CryptoProcessor
6. PKCS11CryptoProcessor: this is the backend for any PCKS11 device for the
processor. For example Luna SafeNet HSM, Thales HSM or SoftHSM.
Is this kind of effort needed or appreciated in the context of Common
Crypto?
Any comment? This is essentially a request for comment.
RE: [CRYPTO] High level API for Common crypto
Posted by "Chen, Haifeng" <ha...@intel.com>.
Hi Giorgio,
Sure please fire JIRA if you like. Folks can discuss in the JIRA.
-----Original Message-----
From: Giorgio Zoppi [mailto:giorgio.zoppi@gmail.com]
Sent: Monday, May 16, 2016 4:23 PM
To: Commons Developers List <de...@commons.apache.org>
Subject: Re: [CRYPTO] High level API for Common crypto
Hello Heighen,
I extened a bit the concept (gold plating). The ideal thing is to create an extension as you did at OpensslNative.c that supports pkcs11. Can i provide a JIRA and do the same thing, maintaining the same interface?
Best Regards,
Giorgio
On Mon, May 16, 2016 at 5:09 AM, Chen, Haifeng <ha...@intel.com>
wrote:
> Hi Zoppi,
> The current API design of Commons Crypto basically follows the similar
> way of the Cipher API and Stream API in java.
>
> You mentioned another API style. I am not so familiar with HSM.
> So the question is: Are there any specific reasons that Cipher style
> API cannot be used for the implementation of cryto using HSM?
>
> Thanks,
> Haifeng
>
>
> From: Giorgio Zoppi [mailto:giorgio.zoppi@gmail.com]
> Sent: Saturday, May 14, 2016 3:48 AM
> To: dev@commons.apache.org
> Subject: [CRYPTO] High level API for Common crypto
>
> Dear all,
> I have been really happy to see an effort for a crypto api in
> apache.org< http://apache.org>, so i decided to provide for comment a
> design of an high level. Many cryptosystem around the world are using
> hardware security modules so the idea to integrate the that in an
> opensource api is pretty cool. In the attached image you may see the
> first raw design. I will explain the rational:
> 1. CryptoOperation: this is the interface that you want to extend for
> your own operation. That they may be simple or composite. In the
> cryptoworld you may want to execute and AES and than from that
> cipherered you may want do something else, an xor with some padding
> for example. So it is nice to provide composite for this reason. Or
> another example Create a key pair with NIST 192 and than sign some data.
> 2. SimpleCryptoOperation: AESCiphering, ECPublicKeyCrreating. A single
> shot of execution.
> 3. CompoundCryptoOperation: a composite (a la compositte design
> pattern) of single operation. The executor of the operation will get
> the output of the first operation as input of the second operation.
> 4. CryptoProcessor: An executor of cryptographic operation (simple or
> composite) potentially may be local or remote. The CryptoProcessor is
> the interface.
> 5. OpenSSLCryptoProcessor: this the backend of the CryptoProcessor 6.
> PKCS11CryptoProcessor: this is the backend for any PCKS11 device for
> the processor. For example Luna SafeNet HSM, Thales HSM or SoftHSM.
> Is this kind of effort needed or appreciated in the context of Common
> Crypto?
> Any comment? This is essentially a request for comment.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [CRYPTO] High level API for Common crypto
Posted by Giorgio Zoppi <gi...@gmail.com>.
Hello Heighen,
I extened a bit the concept (gold plating). The ideal thing is to create an
extension as you did at OpensslNative.c that supports pkcs11. Can i provide
a JIRA and do the same thing, maintaining the same interface?
Best Regards,
Giorgio
On Mon, May 16, 2016 at 5:09 AM, Chen, Haifeng <ha...@intel.com>
wrote:
> Hi Zoppi,
> The current API design of Commons Crypto basically follows the similar way
> of the Cipher API and Stream API in java.
>
> You mentioned another API style. I am not so familiar with HSM.
> So the question is: Are there any specific reasons that Cipher style API
> cannot be used for the implementation of cryto using HSM?
>
> Thanks,
> Haifeng
>
>
> From: Giorgio Zoppi [mailto:giorgio.zoppi@gmail.com]
> Sent: Saturday, May 14, 2016 3:48 AM
> To: dev@commons.apache.org
> Subject: [CRYPTO] High level API for Common crypto
>
> Dear all,
> I have been really happy to see an effort for a crypto api in apache.org<
> http://apache.org>, so i decided to provide for comment a design of an
> high level. Many cryptosystem around the world are using hardware security
> modules so the idea to integrate the that in an opensource api is pretty
> cool. In the attached image you may see the first raw design. I will
> explain the rational:
> 1. CryptoOperation: this is the interface that you want to extend for your
> own operation. That they may be simple or composite. In the cryptoworld you
> may want to execute and AES and than from that cipherered you may want do
> something else, an xor with some padding for example. So it is nice to
> provide composite for this reason. Or another example Create a key pair
> with NIST 192 and than sign some data.
> 2. SimpleCryptoOperation: AESCiphering, ECPublicKeyCrreating. A single
> shot of execution.
> 3. CompoundCryptoOperation: a composite (a la compositte design pattern)
> of single operation. The executor of the operation will get the output of
> the first operation as input of the second operation.
> 4. CryptoProcessor: An executor of cryptographic operation (simple or
> composite) potentially may be local or remote. The CryptoProcessor is the
> interface.
> 5. OpenSSLCryptoProcessor: this the backend of the CryptoProcessor
> 6. PKCS11CryptoProcessor: this is the backend for any PCKS11 device for
> the processor. For example Luna SafeNet HSM, Thales HSM or SoftHSM.
> Is this kind of effort needed or appreciated in the context of Common
> Crypto?
> Any comment? This is essentially a request for comment.
>
RE: [CRYPTO] High level API for Common crypto
Posted by "Chen, Haifeng" <ha...@intel.com>.
Hi Zoppi,
The current API design of Commons Crypto basically follows the similar way of the Cipher API and Stream API in java.
You mentioned another API style. I am not so familiar with HSM.
So the question is: Are there any specific reasons that Cipher style API cannot be used for the implementation of cryto using HSM?
Thanks,
Haifeng
From: Giorgio Zoppi [mailto:giorgio.zoppi@gmail.com]
Sent: Saturday, May 14, 2016 3:48 AM
To: dev@commons.apache.org
Subject: [CRYPTO] High level API for Common crypto
Dear all,
I have been really happy to see an effort for a crypto api in apache.org<http://apache.org>, so i decided to provide for comment a design of an high level. Many cryptosystem around the world are using hardware security modules so the idea to integrate the that in an opensource api is pretty cool. In the attached image you may see the first raw design. I will explain the rational:
1. CryptoOperation: this is the interface that you want to extend for your own operation. That they may be simple or composite. In the cryptoworld you may want to execute and AES and than from that cipherered you may want do something else, an xor with some padding for example. So it is nice to provide composite for this reason. Or another example Create a key pair with NIST 192 and than sign some data.
2. SimpleCryptoOperation: AESCiphering, ECPublicKeyCrreating. A single shot of execution.
3. CompoundCryptoOperation: a composite (a la compositte design pattern) of single operation. The executor of the operation will get the output of the first operation as input of the second operation.
4. CryptoProcessor: An executor of cryptographic operation (simple or composite) potentially may be local or remote. The CryptoProcessor is the interface.
5. OpenSSLCryptoProcessor: this the backend of the CryptoProcessor
6. PKCS11CryptoProcessor: this is the backend for any PCKS11 device for the processor. For example Luna SafeNet HSM, Thales HSM or SoftHSM.
Is this kind of effort needed or appreciated in the context of Common Crypto?
Any comment? This is essentially a request for comment.