Circling back on this, I think I can use the AES-GCM mode of operation already provided as a GMAC to achieve what I'm looking for. If so, I probably won't put forth the effort to implement additional MACs. If it turns out that I do need a MAC algorithm that isn't already supported, I'll readdress the issue. Thanks to all for your insights.
On Sun, Feb 24, 2019 at 5:07 AM Benedikt Ritter <brit...@apache.org> wrote: > 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 > > > > > > > > >
