Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It only takes a minute to sign up.
Sign up to join this community
I need to calculate 256-bit hash in my code, using BLAKE2.
I know I can set BLAKE2 to generate itself a 256-bits hash for any data but I´m curious to know what can be safer and faster:
1- Create the 256-bit using Blake2Config module; or 2- Truncate the normal 512-bit result getting the leftmost 32 bytes (256 bits).
In a first time, I guess getting the leftmost 32 bytes can be safer and not so slower than get 256-bits from Blake directly.
Am I wrong? Thanks for any comments.
You should always use config options to select the output size of a hash function.
If you need a standard output size (e.g. 224, 256, 384, 512 bit) use the recommended parameter set.
This mainly applies to standards like SHA-3, where if you use SHA-3-256 you'll get a different (more standard output) than with "Keccak-256", SHA-3-512/256 and SHAKE128-256, which all use something called "domain seperation" (i.e. append a specific byte sequence to the input to get different hashes).
The reason for the first statement is the following:
The config option is always equally good as / better than the manual truncation. In worst case (e.g. SHAKE) it's just simple truncation of an infinitely long key stream and thereby exhibits the same security properties as manual truncation. In best case (e.g. Skein) the selected output size will influence the output, i.e. Skein-256-256 will give a completely different output for a message $m$ than Skein-256-255 will. Obviously this is more secure (and usually not less fast) as it will guarantee you that $Trunc(H_{d}(m),t)\neq H_t(m)$ which may be a desirable property (although rarely needed).
Blake2 corresponds to the second case (i.e. the digest size affects the output). The requested digest size is used as the initial internal chaining value (right after the IV) along with a static constant and the MAC-key (if used). And thereby it affects the hash as much as the IV does which means Blake2b-32 will be vastly different from Blake2b-64 for the same message. This can be found in RFC 7693 on page 4 (variable name) and page 9 (usage of hash size).
