Missing blake2 hash algorithm described in RFC 7693

[jukkar]

I am trying to implement Wireguard VPN in Zephyr and Wireguard needs blake2 hash algorithm which is missing from PSA. It would be very useful if PSA would support Blake2 out of the box.

The Blake2 RFC can be found here https://datatracker.ietf.org/doc/html/rfc7693

[athoelke]

Are there specific variants of blake2 that you need?

The RFC defines two variable-length hash function and two keyed MACs; and goes on to specify 8 hash algorithm OIDs with specific length outputs.

Although we could add more general support for blake2, we do not currently have an API that is a good fit for variable length hashes. In contrast, it will be simple to add algorithm identifiers for any of the fixed-size hashes or MACs that you need from the RFC.

[jukkar]

Are there specific variants of blake2 that you need?

The Wireguard implementation would need the blake2s variant.

[athoelke]

@jukkar - Does Wireguard need a specific hash output length, such as blake2s/256 (32 bytes)? And/or a variable output length which is more like a limited output XOF? Or the keyed-hash which looks like a MAC - and if so, with what sized keys and output tag lengths?

[jukkar]

Does Wireguard need a specific hash output length, such as blake2s/256 (32 bytes)?

It uses both 16 and 32 byte length outputs.
For the key lengths, both 0 and 32 values are being used. Specifically the key length value 32 is only used if output length is 16.

[athoelke]

From that, it seems to me that you need:

1. A hash algorithm that outputs 32 bytes/256 bits. This could be called PSA_ALG_BLAKE2S_HASH_256.
2. A MAC algorithm that accepts a 32-byte key, and outputs a 16-byte authentication tag. This could be called PSA_ALG_BLAKE2S_MAC.

For the MAC, we would specify that a key of any length from 1 to 32 bytes is accepted (but recommend at least 16 bytes). The output length could default to 16 bytes (which must be supported), but we could specify that an implementation can support any tag length output from 1 to 32 bytes (as the underlying algorithm permits this).

Would this meet the needs of Wireguard?

[athoelke]

I might be tempted to have the default tag length for PSA_ALG_BLAKE2S_MAC be 32 bytes (the maximum output), and specify that the implementation needs to support a 16-byte truncated tag to be useful for Wireguard?

This is partly driven by the fact that if we also add blake2b support, then the only way to have a 64-byte tag for the MAC is to have that be the 'default tag length' (when the algorithm identifier encoding has TAG_LEN = 0) as the truncated tag length in the encoding only supports values 1 to 63. If we do that, it makes sense for blake2s to follow the same pattern.

[jukkar]

Sounds like a good plan that should work for Wireguard.

[athoelke]

I would propose to provide identifiers for both Blake2s and Blake2b, as follows.

BLAKE2s

The general form of BLAKE2s is a keyed PRF that accepts keys of 0 to 32 bytes and outputs a digest of 1 to 32 bytes.

Propose:

• A 256-bit (32 byte) hash function.
• A MAC that accepts 1-32 byte keys, and outputs 1-32 byte tags. The default (LEN = 0) tag length is 32 bytes.

PSA_ALG_BLAKE2S_HASH256
PSA_ALG_BLAKE2S_MAC

BLAKE2b

The general form of BLAKE2b is a keyed PRF that accepts keys of 0 to 64 bytes and outputs a digest of 1 to 64 bytes.

Propose:

• A 512-bit (64 byte) hash function.
• A MAC that accepts 1-64 byte keys, and outputs 1-64 byte tags. The default (LEN = 0) tag length is 64 bytes.

PSA_ALG_BLAKE2B_HASH512
PSA_ALG_BLAKE2B_MAC

[MarcusJGStreets]

I assume nobody is using the parallel versions, Blake2bp and Blake2sp?
They are quicker on SIMD capable processors, but are different algorithms.

If we are adding Blake2, is it worth adding Blake3?