<Would your implementation be based on wrapping low level APIs to provide a more performant implementation to Java developers? If so I think it can we added to crypto.>
Yes. My current thinking is that I'd simply expose the existing relevant OpenSSL functions via JNI and JNA by mapping them to the JCE API for the Mac class to the extent possible. Essentially, I'd follow the established pattern for the cipher and random functionality currently exposed. On Fri, Feb 22, 2019 at 6:52 AM Benedikt Ritter <brit...@apache.org> wrote: > Hello Alex, > > welcome to the Apache Commons Developers list! > > Am Fr., 22. Feb. 2019 um 03:01 Uhr schrieb Alex Remily < > alex.rem...@gmail.com>: > > > Team, > > > > What do you think about adding HMAC and CMAC functionality to commons > > crypto? I have a project I'd like to use it for, so I don't mind working > > on the implementation, but I don't want to make the effort if there's no > > support for the idea. > > > > I haven't done a lot of work on crypto and I'm not a crypto expert. So I > can not say if your proposal fits into the scope of Commons Crypto. However > the components description provides some guidance here: > > > Apache Commons Crypto is a cryptographic library optimized with AES-NI > (Advanced Encryption Standard New Instructions). It provides Java API for > both cipher level and Java stream level. Developers can use it to implement > high performance AES encryption/decryption with the minimum code and > effort. Please note that Apache Commons Crypto doesn't implement the > cryptographic algorithm such as AES directly. It wraps to Openssl or JCE > which implement the algorithms. > > Would your implementation be based on wrapping low level APIs to provide a > more performant implementation to Java developers? If so I think it can we > added to crypto. > > Regards, > Benedikt > > > > > > Thoughts? > > > > Alex > > >
