[crypto] Implementing HMAC and CMAC

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

[crypto] Implementing HMAC and CMAC

Alex Remily
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.

Thoughts?

Alex
Reply | Threaded
Open this post in threaded view
|

Re: [crypto] Implementing HMAC and CMAC

Benedikt Ritter-4
Hello Alex,

welcome to the Apache Commons Developers list!

Am Fr., 22. Feb. 2019 um 03:01 Uhr schrieb Alex Remily <
[hidden email]>:

> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: [crypto] Implementing HMAC and CMAC

Bernd Eckenfels
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 <[hidden email]>
Gesendet: Freitag, Februar 22, 2019 12:52 PM
An: Commons Developers List; [hidden email]
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 <
[hidden email]>:

> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: [crypto] Implementing HMAC and CMAC

Alex Remily
In reply to this post by Benedikt Ritter-4
<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.

On Fri, Feb 22, 2019 at 6:52 AM Benedikt Ritter <[hidden email]> wrote:

> Hello Alex,
>
> welcome to the Apache Commons Developers list!
>
> Am Fr., 22. Feb. 2019 um 03:01 Uhr schrieb Alex Remily <
> [hidden email]>:
>
> > 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
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [crypto] Implementing HMAC and CMAC

Alex Remily
In reply to this post by Bernd Eckenfels
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 <[hidden email]>
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 <[hidden email]>
> Gesendet: Freitag, Februar 22, 2019 12:52 PM
> An: Commons Developers List; [hidden email]
> 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 <
> [hidden email]>:
>
> > 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
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [crypto] Implementing HMAC and CMAC

sebb-2-2
In reply to this post by Alex Remily
On Sat, 23 Feb 2019 at 02:33, Alex Remily <[hidden email]> 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 <[hidden email]> wrote:
>
> > Hello Alex,
> >
> > welcome to the Apache Commons Developers list!
> >
> > Am Fr., 22. Feb. 2019 um 03:01 Uhr schrieb Alex Remily <
> > [hidden email]>:
> >
> > > 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [crypto] Implementing HMAC and CMAC

Alex Remily
<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 <[hidden email]> wrote:

> On Sat, 23 Feb 2019 at 02:33, Alex Remily <[hidden email]> 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 <[hidden email]>
> wrote:
> >
> > > Hello Alex,
> > >
> > > welcome to the Apache Commons Developers list!
> > >
> > > Am Fr., 22. Feb. 2019 um 03:01 Uhr schrieb Alex Remily <
> > > [hidden email]>:
> > >
> > > > 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [crypto] Implementing HMAC and CMAC

Benedikt Ritter-4
Hi,

Am So., 24. Feb. 2019 um 00:31 Uhr schrieb Alex Remily <
[hidden email]>:

> <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 <[hidden email]> wrote:
>
> > On Sat, 23 Feb 2019 at 02:33, Alex Remily <[hidden email]> 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 <[hidden email]>
> > wrote:
> > >
> > > > Hello Alex,
> > > >
> > > > welcome to the Apache Commons Developers list!
> > > >
> > > > Am Fr., 22. Feb. 2019 um 03:01 Uhr schrieb Alex Remily <
> > > > [hidden email]>:
> > > >
> > > > > 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [crypto] Implementing HMAC and CMAC

Alex Remily
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 <[hidden email]> wrote:

> Hi,
>
> Am So., 24. Feb. 2019 um 00:31 Uhr schrieb Alex Remily <
> [hidden email]>:
>
> > <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 <[hidden email]> wrote:
> >
> > > On Sat, 23 Feb 2019 at 02:33, Alex Remily <[hidden email]>
> 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 <[hidden email]>
> > > wrote:
> > > >
> > > > > Hello Alex,
> > > > >
> > > > > welcome to the Apache Commons Developers list!
> > > > >
> > > > > Am Fr., 22. Feb. 2019 um 03:01 Uhr schrieb Alex Remily <
> > > > > [hidden email]>:
> > > > >
> > > > > > 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: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
> >
>