Hi Giorgio, Sure please fire JIRA if you like. Folks can discuss in the JIRA.
-----Original Message----- From: Giorgio Zoppi [mailto:giorgio.zo...@gmail.com] Sent: Monday, May 16, 2016 4:23 PM To: Commons Developers List <dev@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 <haifeng.c...@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.zo...@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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
