[PATCH v2 2/7] nest: Add Blake2s and Blake2b hash functions

[Toke Høiland-Jørgensen]

Ondrej Zajicek <santiago at crfreenet.org> writes:

> On Mon, Nov 16, 2020 at 11:31:14PM +0100, Toke Høiland-Jørgensen wrote:
>> Toke Høiland-Jørgensen <toke at toke.dk> writes:
>> 
>> > @@ -169,6 +170,12 @@ const struct mac_desc mac_table[ALG_MAX] = {
>> >    [ALG_SHA256] = 	HASH_DESC("Keyed SHA-256",	sha256,	SHA256),
>> >    [ALG_SHA384] = 	HASH_DESC("Keyed SHA-384",	sha384,	SHA384),
>> >    [ALG_SHA512] = 	HASH_DESC("Keyed SHA-512",	sha512,	SHA512),
>> > +  [ALG_BLAKE2S] = 	{"Blake2s", BLAKE2S_SIZE, sizeof(struct blake2s_context),
>> > +                         blake2s_bird_init, blake2s_bird_update,
>> > +                         blake2s_bird_final, BLAKE2S_SIZE, BLAKE2S_BLOCK_SIZE},
>> > +  [ALG_BLAKE2B] = 	{"Blake2b", BLAKE2B_SIZE, sizeof(struct blake2b_context),
>> > +                         blake2b_bird_init, blake2b_bird_update,
>> > +                         blake2b_bird_final, BLAKE2B_SIZE, BLAKE2B_BLOCK_SIZE},
>> 
>> Note that there's an ongoing discussion on the babel at ietf list about
>> whether the output size of Blake2s ought to be truncated to 128 bits.
>> 
>> See:
>> https://mailarchive.ietf.org/arch/msg/babel/9EIUxXvaGj-Zm9uktF0v1Zavb-g/
>> 
>> If anyone here has an opinion on this, please weigh in on that list;
>> otherwise I plan to respin this series with an option to have both
>> 128-bit and 256-bit outputs from Blake2s.
>
> Hi
>
> Well, if Blake2 has variants with reduced hash lengths,

It allows you to specify any output length up to the max and just
truncates the output to that length...

> than these lengths should be part of the hash name (like in SHA-2),
> even if only one would be implemented. So they should have keywords
> like blake2s256.
>
> Like in OpenSSL:
> blake2b512        blake2s256        gost              md4
> md5               rmd160            sha1              sha224
> sha256            sha3-224          sha3-256          sha3-384
> ...
>
> Or like in RFC 7693 section 4.

Yeah, that was my plan!

> Also, even if Babel WG have selected 128-bit reduced hash length variant
> as suggested variant, it would make sense to have full-length variants
> implemented in BIRD as they are basic variants of that hash.

Yup, will do; I already did add "extra" algorithms: blake2b is not
specified by the spec, and neither are most of the other algorithms
supported by Bird, but the proto/babel can still use them, obviously.

-Toke