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. >
