Add Blake2b-256, Blake2b-128, etc. as wrappers over VarBlake2b.

[dpc]

It looks like some crates want a D: Digest<OutputSize = U64> + Default as an argument to what hash to use, so that VarBlake2b is not very useful on it's own. Eg. dalek-cryptography/ed25519-dalek#59

I could write my own wrapper, but if I need it, other people will, too.

[newpavlov]

Yes, we should do it as part of blake2. Though instead of wrappers a better option will be to write a generic implementation over output size (something like GenBlake2b<N>), maybe with some convenience aliases (e.g. type Blake2b256 = GenBlake2b<U32>). Luckily typenum allows us to define "less or equal" bounds, though IIRC we will not be able to migrate it straightforwardly to const generics in future. I think older versions of blake2 had such genericity, but were removed in favor of implementing VariableOutput.

[newpavlov]

Forgot to ask: can you do a PR with these updates?

[dpc]

Most people will want 128, 256, 512 versions only, and they can be always changed to whatever is the best option for the internal type, in the future, no? In a backward compat way, for whichever method is used. So is there any point to complicate everything with typenum already?

[dpc]

I could do it with a simple macro... :D

[newpavlov]

Crates already have been "complicated" with typenum. :) I would prefer to have a more universal and flexible solution (e.g. how about 384 bit hashes used with signatures? or maybe someone will want to replace CRC32 checksum?), plus it will not be that difficult to implement, you'll just need to make generic this struct and associated impls, and create necessary type aliases.

[dpc]

Ok then I'll see what I can do.

[dpc]

I would like to confirm something? Is the only difference between Blake with 512bit output and Blake with 256bit output, that the shorter one does everything the same and takes only first 32 bytes of the result? Is this standardized somewhere, arbitrary, common convention? I'm not a cryptographer.

[burdges]

As a rule, the NIST competition bit size specifiers correspond to both security level and output size, which creates a mess. It's why you should use shake128/256, not sha3. I donno about blake2b specifically, but good for them if they avoided that noise.

[dpc]

@burdges From (wikipeidia)[https://en.wikipedia.org/wiki/BLAKE_(hash_function)#BLAKE2]:

BLAKE-256 and BLAKE-224 use 32-bit words and produce digest sizes of 256 bits and 224 bits, respectively, while BLAKE-512 and BLAKE-384 use 64-bit words and produce digest sizes of 512 bits and 384 bits, respectively.[1].

So I guess the block size is different, which probably leads to different hashes?

The thing is, in my code I already used existing Blake2b and I just took first 32bytes of the hash, because "it's too long, and 256bits should be enough for me". And now I wonder if I did something stupid, or at very least am I deviating from the standards much.

[dpc]

I tested it, and it looks like VarBlake2b::variable_result of size 32 is different than just first bytes of normal Blake2b::fixed_result. So my PR is most probably wrong, and my taking just first 32 bytes of 64 output, is not standard.

[newpavlov]

Different output sizes use a slightly different initialization of initial state, so it's not a simple truncation. I will look into your PR to if you've missed something.

[nazar-pc]

I found it quite inconsistent that Blake2b512 and Blake2s256 type aliases exist, but Blake2b256, which is very common, doesn't.

[newpavlov]

@nazar-pc
Feel free to open PR with such addition.