> This is not actually signing algorithm but MAC algorithm, right? > And this is using the native BLAKE2B MAC mode (RFC7693), right?
Apologies for my incorrect usage of the terms. Yes, we're talking about Blake2b MAC mode. For some reason, I've missed the JWA section that explains the registration process (https://www.rfc-editor.org/rfc/rfc7518.html#section-7.1). I'll follow it. Thanks for your input. On Mon, 11 Apr 2022 at 12:08, Ilari Liusvaara <[email protected]> wrote: > On Wed, Apr 06, 2022 at 07:15:24PM +0200, Luís Cobucci wrote: > > Hello there, > > > > I'm a maintainer of a JWT library for PHP and we're discussing about > > adding a non-standard signing algorithm: Blake2b ( > > https://github.com/lcobucci/jwt/pull/832). > > > > That algorithm is quite attractive due to: > > - min key length requirement (libsodium requires at least 128bit keys) > > - performance > > > > What are your thoughts on this? Is there a chance to add Blake2b as > > an optional algorithm? > > This is not actually signing algorithm but MAC algorithm, right? > > And this is using the native BLAKE2B MAC mode (RFC7693), right? > > > I note that some texts in patch refrence HMAC: HMAC is generic > construction to turn a hash function into MAC. The native BLAKE2B MAC > is not HMAC (which allows it to be more efficient than HMAC-BLAKE2B). > > > Even if not the case here, sigantures using BLAKE2B as hash would be > significantly more problematic: The only space/time efficient signature > algorithm allowing variable hashes that is even close to widespread is > ECDSA, and ECDSA requires bit order of hash, which BLAKE2 just does not > specify. > > > As for process for adding it, I would write Internet-Draft specifying > the use in JOSE and then use the I-D as specification for expert > review. One might do a comment round through this list first to catch > the worst issues... > > > > -Ilari >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
