On 12/10/24 19:51, Peter Dimov via Boost wrote:
Andrey Semashev wrote:
I think, HashAlgorithm should allow implementations to use the seed arguments to the hash algorithm constructors as salt, i.e. the constructor would implicitly call update().
No, this is a bad practice and should never be used. As I already said, the algorithm should at minimum include the size of the seed, and then pad to a multiple of the block size.
Is this something that should be intrinsically supported by HashAlgorithm, though? Can it be an external component, such as a free function or an adapter like hmac<>? Currently, as I look in the hash algorithms provided by Boost.Hash2, most of them interpret the byte-range seed the way you describe, with the exception of fnv1a and siphash. fnv1a doesn't append the seed size (and doesn't pad as FNV-1a is not a block hash); I'm not sure if that's intentional. siphash has special treatment of the seed if it is exactly 8 bytes. Given these differences, is the user able to have any sort of guarantee on consistent behavior of the constructors of various algorithms? If not, why provide the constructor at all? I think, it would be better if the library provided a standalone component that would seed any hash algorithm (whether implemented by Boost.Hash2 or not) in a consistent and secure way.