The answer you linked doesn't say that truncating a Blake2 is always unsafe. (HMAC-Blake2 is not unsafe-it's just not the canonical way of using Blake2 as a MAC.) you wouldn't want to use HMAC, since Blake2 has a built in optional keyed mode with the same MAC/PRF goals as HMAC. So yes, this substitution should be safe if Blake2 is safe. 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.SHA-256 is conjectured to be collision resistant, preimage resistant and second preimage resistant.Note that Blake2's security goals are a superset of those of SHA-256: 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? Would it make any difference for me to use Blake2 for checksums and signing instead of SHA-256? Is there any difference in security? the Go implementations of Blake2s and Blake2b don't provide 128bit checksums.My project is in Go which supports both SHA-256 and Blake2.My application runs on both 32-bit systems (e.g.Keys are derived from human-generated passwords.I rarely need to derive keys, probably a dozen times per day.The resulting 96 bytes form the key header. signs the concatenated work factors and checksum using HMAC SHA-256, appending the signature to the header.checksums these bytes using SHA-256 and appends the first 16 bytes of the checksum to the header.
I use scrypt as a key derivation function (not to store passwords).
0 kommentar(er)
