Confusing wording about stability about highwayhash

[jan-wassenberg]

Thanks for reaching out! I'm sorry about the delay, am now back from vacation.

Yes, that's trying to say that once declared frozen, HighwayHash will not change,
but we have indeed been waiting for internal and external feedback before freezing.

We have two applications that intend to use HWH 1.0, so it'll probably be frozen soon (< 3 months).

What's your timeline? We may be able to decide to freeze it earlier if that would help you.

[jan-wassenberg]

Good news, we have indeed frozen HighwayHash64 (as well as the C++ implementation that returns HHResult64). The readme is updated accordingly.

The 128 and 256 bit functions (in particular: their finalization method) are not yet frozen.

[schoedl]

We are interested in the 128-bit version. Any idea when it will be frozen?

Thx!

[jan-wassenberg]

Thanks for reaching out! It is difficult to promise a date because of other commitments, but I'd imagine it can be frozen within a few months.
In the meantime, would versioning (storing a version flag, need only be zero or one) be an option?

[schoedl]

We are currently on Murmurhash, so we'd stay there until the freeze.
I do understand correctly that the main design difference of Highwayhash over Farmhash is that Farmhash isn't designed for persistent hashing? That's something we need.

[jan-wassenberg]

Sounds good.

FarmHash does provide persistent "fingerprinting" functions, but its 128-bit variant calls CityHash128.

HighwayHash is quite different: it is designed for cross-platform SIMD and is nontrivial to reverse if the seed is unknown (FarmHash multipliers are known, HWH multipliers are unknown to the attacker).

[jan-wassenberg]

@schoedl
Good news, all (64/128/256-bit) variants of HighwayHash are now frozen and will not change.