Closed edward-shen closed 6 months ago
blake 0.10 permits construction of MAC variants with empty keys, but I don't think this is a valid construction of blake2. Using RFC7693 as reference:
blake 0.10
Section 2.5 states the following:
The second (little-endian) byte of the parameter block, "kk", specifies the key size in bytes. Set kk = 00 for unkeyed hashing.
I've to understand this as keyed Blake2 is mutually exclusive with an empty key. Yet Blake2*Mac variants seem to permit this construction with new_with_params. This method will accept an empty key, perform operations to initialize blake2 in keyed mode (e.g. the operations in Section 3.3 that assume kk > 0), but then pass a key length of 0 to new_with_params, which then initializes the parameter block with kk = 0x00.
Blake2*Mac
new_with_params
kk > 0
kk = 0x00
This results in a keyed construction of blake2 buffers with unkeyed initialization which seems incorrect?
If I'm correct, then I think we either need to special-case the empty key when provided to the MAC variants or have empty keys return an error?
blake 0.10permits construction of MAC variants with empty keys, but I don't think this is a valid construction of blake2. Using RFC7693 as reference:Section 2.5 states the following:
I've to understand this as keyed Blake2 is mutually exclusive with an empty key. Yet
Blake2*Macvariants seem to permit this construction withnew_with_params. This method will accept an empty key, perform operations to initialize blake2 in keyed mode (e.g. the operations in Section 3.3 that assumekk > 0), but then pass a key length of 0 tonew_with_params, which then initializes the parameter block withkk = 0x00.This results in a keyed construction of blake2 buffers with unkeyed initialization which seems incorrect?
If I'm correct, then I think we either need to special-case the empty key when provided to the MAC variants or have empty keys return an error?