Hi, Am So., 24. Feb. 2019 um 00:31 Uhr schrieb Alex Remily < alex.rem...@gmail.com>:
> <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. > Let's give this a shot. I like simple solutions that work für 80% of the use cases instead of complex ones that cover 99%. Why don't you create a PR so we can discuss in more details how the final solution should look like? Thank you! Benedikt > > 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 > > > > >
