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.
- 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?