Hi, This is indeed a bug, but I'm not too fond of that fix, as it slightly alters the semantics of the final() function. `outlen` goes from being the size of the output buffer---which may be larger than the hash size---to being exactly, and prescriptively, the hash output size.
The bug's root cause is the fact that `blake2x_init_param` sets the output size `S->outlen` from the `digest_length` parameter, but in this case the output length is meant to be `BLAKE2X_OUT_BYTES`, i.e., the `inner_length` field in the parameter block. https://github.com/BLAKE2/BLAKE2/blob/master/ref/blake2b-ref.c#L92 But the `blake2xp_init_leaf` misses this, and the digest length is used there instead: https://github.com/BLAKE2/BLAKE2/blob/master/ref/blake2bp-ref.c#L30-L46 So the fix should make sure the `blake2xp_init_leaf` sets the correct output length for those nodes. What the cleanest way to achieve this is I am not sure yet, I'll think some more about it. Best regards, Samuel Neves On 10/31/2016 05:05 AM, Pádraig Brady wrote: > I've got this fairly well integrated with coreutils, > and will present a patch perhaps tomorrow. > > In testing I hit a bug in the reference implementation, > where I was getting random values for: > > b2sum -a blake2bp -l8 /dev/null > > I've fixed that up locally with this patch: > > https://github.com/BLAKE2/BLAKE2/pull/36 > > thanks, > Pádraig.
