Xxhash: SipHash zu Benchmarks hinzufügen ...?

Sicher, es ist ein guter Vorschlag.

siphash ist portabel (glaube ich), was die Hauptvoraussetzung ist, um vergleichbar zu sein.
Ich vermute, dass es für die Rohgeschwindigkeit im Nachteil ist, obwohl sein Hauptverkaufsargument darin besteht, dass es einen verbesserten kryptografischen Schutz in Bezug auf die Kollisionsgenerierung bietet.

Ich muss jedoch Zeit finden, um eine neue Benchmark-Plattform dafür zu bauen.

Tatsächlich habe ich bei dieser SMHasher-Gabel einige erste Tests gefunden , die zeigen, dass xxHash bei kleinen Eingaben mindestens doppelt so schnell und bei längeren Eingaben viel schneller ist.

Ich denke aber, das wird nicht reichen...

Das Hauptverkaufsargument von [SipHash] ist, dass es einen verbesserten kryptografischen Schutz in Bezug auf die Kollisionsgenerierung bietet.

Ich denke, dass dies eine größere Anforderung ist, als mir klar war, insbesondere aufgrund der Risiken im Zusammenhang mit Flood-Hashing-Angriffen (für alle anderen, die dies lesen, hier ist eine Erklärung auf hoher Ebene und eine detailliertere ).

Ich habe diesen Thread gefunden, der darauf hinweist, dass es möglich ist, Kollisionen bei Bedarf zu erzeugen.

Ich weiß nicht, ob es möglich ist, diese Schwäche zu nutzen, um Mehrfachkollisionen zu erzeugen und zu Hash-Flooding-Angriffen zu führen ... aber ich denke, ein Widerstand gegen die Kollisionserzeugung sollte als Voraussetzung für eine weit verbreitete Einführung angesehen werden.

...

Als sicherheitsrelevante Randnotiz: Durch das Festlegen der ersten 32 Bytes einer Nachricht auf einen bestimmten Wert sind alle Vektoren nach der ersten Runde gleich dem Seed.

Dies könnte ausgenutzt werden, um Seed-Daten zu extrahieren oder den Hash zu kompromittieren. Ich spiele mit meiner eigenen Variante herum, wo ich irreversible Manipulationen verwende, um dies zu verhindern.

Da ich für die nächste xxHash -Veröffentlichung eine neue Benchmark-Runde machen werde, kann ich genauso gut siphash in die Liste aufnehmen.

FYI:

Ich habe mich von XXHashs Ansatz inspirieren lassen und etwas Ähnliches in meinem eigenen Projekt / meiner eigenen Bibliothek verwendet (ich habe es RiskyHash genannt - den Quellcode finden Sie hier ).

Übrigens:

Je mehr ich lese, desto weniger beeindruckt mich die Notwendigkeit der „Sicherheit“ der Hash-Funktion, wenn es um Hash-Maps geht. IMHO sollte die Hash Map-Implementierung Sicherheitsbedenken behandeln, nicht die Hashing-Funktion. Wenn Sie dieser Logik folgen, könnte die Verwendung einer schnelleren Hashing-Funktion zu einer erheblichen Leistungssteigerung führen.

Ja, IMO, SipHash ist übertrieben. Selbst bei der „schnellen“ 1-3 Variante liegt seine Leistung bei weniger als der Hälfte von XXH32.

Sie brauchen nur einen anständigen Hash:

1. Der Hasch muss pflanzbar sein. Jeder ungesäte Hash kann vorberechnet werden. Hashes haben praktisch unendlich viele Kollisionen, so einfach ist es, sie zu finden.
2. Keine Seed-unabhängigen Kollisionen. Der MurmurHash-Vorfall war so eine große Sache, weil Sie leicht Werte generieren konnten, die unabhängig vom Schlüssel kollidieren würden. Es spielt keine Rolle, welchen Samen du verwendest, Haschisch ist scheiße.
3. Es muss eine gute Verteilung haben. Dadurch wird sichergestellt, dass die Eimer gleichmäßig gefüllt sind, und Sie können die Größe auf eine Potenz von 2 ändern und einen Modul vermeiden.
4. Es muss schnell sein. Der ganze Sinn einer Hash-Tabelle besteht darin, so schnell wie möglich zu sein. Wenn Sie 64 Zyklen pro Byte ausgeben, warum sollten Sie sich die Mühe machen?

Siphash hinzugefügt
https://github.com/Cyan4973/xxHash/wiki/Leistungsvergleich