hash: Implement xxHash

[weltling]

The implementation bundles the xxHash v0.8.0 release and includes all the variants

• xxh32, 32-bit wide
• xxh64, 64-bit wide
• xxh3, 64-bit wide
• xxh128, 128-bit wide

An initial hash state can be passed through the options arrray. An additional
functionality not targeted in this implementation is the secret support in xxh3
and xxh128. That can be added at a later point.

The serialization for xxh3 and xxh128 should not be implemented, as the
state would contain the secret. Despite the xxHash is a non crypto
algorithm, the secret would be serialized as plain text which would be
insecure.

Signed-off-by: Anatol Belski ab@php.net

[weltling]

@m6w6@nikic ^

[weltling]

Would someone have time to take a look?

Thanks.

[m6w6]

LGTM!

[weltling]

Thanks for the check! I'll plan to finish this up soon.

[nikic]

The serialization for xxh3 and xxh128 should not be implemented, as the
state would contain the secret. Despite the xxHash is a non crypto
algorithm, the secret would be serialized as plain text which would be
insecure.

I don't get your reasoning here. In what way is xxHash different from all other hash algorithms? In the paragraph before you also say that secret support is not targeted.

[weltling]

Hi, thanks for checking. To compare is here XXH3_state_s vs. for example XXH64_state_s. Both XXH3 and XXH128 will use the former and they support passing a secret that will be involved, to check XXH3_update for an example. Adding the support for it is as easy as extending the config options to support it. I'd eventually do it, so knowing that ahead it was clear these two should not be serialized. The call would then look similar to $h = hash("xx3", $str, options: ["secret" => "my secret"]);.

Another part here - as one can see, the secret in XXH3_state_s is a pointer. That means, it can't be stored by just using a serialization format, it needs to be handled a specific way. We previously had a discussion on an approach to serialize the initial seed state in the murmur PR. For the time being it's not serialized as nothing requires the initial seed state after the init (though it would be useful for the error reporting,). Serializing a "snapshot" of the context consisting on just scalar datatypes seems fine enough and doesn't overload the context struct itself. I guess this part brings us back to that discussion and seems cases like this would still require saving data into the php object part, not into the actual context struct. Still in xxHash case there isn't a hard requirement to serialize the secret as it would be insecure. I guess the more cases come, some strategy might show more clear.

Thanks