Should I use SHA256 or Blake2 to checksum and sign scrypt headers?

Question

I use scrypt as a key derivation function (not to store passwords). To pass around the detached key header I use the standard encoding as implemented in Colin Percival's scrypt implementation (scryptenc.c#L224).

The original scrypt key header encoding

• binary encodes an algorithm identifier ("scrypt\0"), logN, r, p and salt into a 48 bytes header
• checksums these bytes using SHA-256 and appends the first 16 bytes of the checksum to the header
• signs the concatenated work factors and checksum using HMAC SHA-256, appending the signature to the header

The resulting 96 bytes form the key header.

My requirements

• I rarely need to derive keys, probably a dozen times per day.
• Keys are derived from human-generated passwords
• My application runs on both 32-bit systems (e.g. smartphones) and 64-bit desktops.
• My project is in Go which supports both SHA-256 and Blake2
• the Go implementations of Blake2s and Blake2b don't provide 128bit checksums

Would it make any difference for me to use Blake2 for checksums and signing instead of SHA-256? Is there any difference in security?

If I use Blake2-256, would I cut off 16 bytes for the checksum (this seems to be not recommended), use 32 bytes or just keep it as is using SHA-256?

Thanks!

Answer 1

Note that Blake2's security goals are a superset of those of SHA-256:

• SHA-256 is conjectured to be collision resistant, preimage resistant and second preimage resistant.
• Blake2 is conjectured to be random oracle indifferentiable, a stronger property that SHA-256 doesn't have, and which implies the three classic hash function properties.

So yes, this substitution should be safe if Blake2 is safe. One thing to note is that for this step:

• signs the concatenated work factors and checksum using HMAC SHA-256, appending the signature to the header

...you wouldn't want to use HMAC, since Blake2 has a built in optional keyed mode with the same MAC/PRF goals as HMAC. (HMAC-Blake2 is not unsafe—it's just not the canonical way of using Blake2 as a MAC.)

If I use Blake2-256, would I cut off 16 bytes for the checksum (this seems to be not recommended), use 32 bytes or just keep it as is using SHA-256?

The answer you linked doesn't say that truncating a Blake2 is always unsafe. The gist of it is that:

• It's generally wiser and safer to stick to well-trodden paths than to improvise your own; if there's a well-understood, standard way of achieving X, then that should generally be your default choice. (Note that this implies you should stick to SHA-256 for the application you describe!)
• When hashing to a custom output size, it's sometimes safer to make the hash output depend on the desired output size, to close off attacks where somebody is able to trick a system into hashing the same input in different contexts but truncated to different lengths. (More generally, whether truncating a hash function is safe or not depends on how it's used.)

In your situation, I would go back to the fact that you're taking an already designed protocol and replacing its use of SHA-256 with Blake2. This means that if the protocol is secure, then your substitution should be secure as well, because if Blake2 is secure then it should have all the properties that the protocol expects from SHA-256. So if the original protocol truncates the output of SHA-256, then it should be no worse to truncate the output of Blake2.