<Would this affect the attempt to support multiple OpenSSL versions?>
That's an open question. I think we could use the same approach we used to support 1.0 and 1.1 for cipher and random. Of course, as you noted, the workload would increase to support additional versions, but I don't think implementing MAC would otherwise hamstring the overall effort. <I'm not saying this applies here, but is something to be aware of: Every new piece of code requires maintenance, so ideally only the minimal extra code should be added. If in doubt, leave it out. It can be added later if it turns out to be needed, but once added, is much harder to drop.> Fair point, which I think ties into the earlier comment about whether the benefit of native performance applies equally to a MAC as it does to a cipher. I suppose I could do a minimal implementation and run a bake-off to help determine whether the juice is worth the squeeze. I know that I'd like to see if it makes a difference in my own project, but beyond that I've no idea what the demand is for MAC as a feature. On Sat, Feb 23, 2019 at 6:01 AM sebb <seb...@gmail.com> wrote: > On Sat, 23 Feb 2019 at 02:33, Alex Remily <alex.rem...@gmail.com> wrote: > > > > <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. > > Seems like a good approach. > > Would this affect the attempt to support multiple OpenSSL versions? > > I'm not saying this applies here, but is something to be aware of: > Every new piece of code requires maintenance, so ideally only the > minimal extra code should be added. > If in doubt, leave it out. It can be added later if it turns out to be > needed, but once added, is much harder to drop. > > > 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 > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
