I don't have any algorithm-specific quantitative analysis to reference specifically regarding native vs JCE performance, but my intuition is that a performance boost from dropping into native code comes from eliminating the overhead from the JVM abstraction layer more than anything else, with perhaps some contribution from use of compiler hints in the native code base. Following my intuition, the performance increase to a calling process would be more a function of the length of the input to the cipher or MAC than of the algorithm, i.e., the more rounds processed by native code, the smaller the setup overhead of context switching as a portion of the algorithm runtime. Why wouldn't we expect to see a performance boost from native MAC analogous to that achieved by the cipher?
On Fri, Feb 22, 2019 at 8:43 AM Bernd Eckenfels <e...@zusammenkunft.net> wrote: > Hello, > > I think crypto is rather special for native - not sure if you can get the > same speedup from a native HMAC compared to the JCE Version. So a HMAC > utility is mostly about convenience, and that already exists in > commons-codec in HmacUtils. > > The only thing which would be a good fit as it does not work well with JCE > would be a iterated application like PBKDF2 with HMAC (because of the > optimization step of precalculating) > > Gruss > Bernd > > Gruss > Bernd > -- > http://bernd.eckenfels.net > > ________________________________ > Von: Benedikt Ritter <brit...@apache.org> > Gesendet: Freitag, Februar 22, 2019 12:52 PM > An: Commons Developers List; s...@apache.org > Betreff: Re: [crypto] Implementing HMAC and CMAC > > 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 > > >
