Re: [crypto] Implementing HMAC and CMAC

[Alex Remily <al...@gmail.com>]

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 <br...@apache.org> wrote:

> Hi,
>
> Am So., 24. Feb. 2019 um 00:31 Uhr schrieb Alex Remily <
> alex.remily@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 <se...@gmail.com> wrote:
> >
> > > On Sat, 23 Feb 2019 at 02:33, Alex Remily <al...@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 <br...@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.remily@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-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > >
> >
>