Xxhash: ¿Agregar SipHash a los puntos de referencia...?

Claro, es una buena sugerencia.

siphash es portátil (creo), que es el principal requisito para ser comparable.
Sospecho que está en desventaja por la velocidad bruta, aunque su principal punto de venta es que ofrece una protección criptográfica mejorada con respecto a la generación de colisiones.

Sin embargo, necesito encontrar tiempo para construir una nueva plataforma de referencia para esto.

En realidad, encontré algunas pruebas iniciales en esta bifurcación SMHasher , que muestran que xxHash es al menos el doble de rápido para entradas pequeñas y mucho más rápido para entradas más largas.

Sin embargo, creo que esto no será suficiente...

El principal punto de venta de [SipHash] es que ofrece una protección criptográfica mejorada con respecto a la generación de colisiones.

Creo que este es un requisito más grande de lo que pensaba, especialmente debido a los riesgos relacionados con los ataques de hash de inundación (para cualquier otra persona que lea esto, aquí hay una explicación de alto nivel y una más detallada ).

Encontré este hilo que indica que es posible producir colisiones a pedido.

No sé si es posible usar esta debilidad para crear colisiones múltiples y provocar ataques de inundación de hash... pero creo que la resistencia a la generación de colisiones debe considerarse un requisito para una adopción generalizada.

...

Como nota al margen relacionada con la seguridad, al establecer los primeros 32 bytes de un mensaje en un valor específico, todos los vectores son iguales a la semilla después de la primera ronda.

Esto podría explotarse para extraer datos semilla o comprometer el hash. Estoy jugando con mi propia variación donde uso manipulaciones irreversibles para evitar esto.

Como voy a hacer una nueva ronda de referencia para el próximo lanzamiento xxHash , también puedo agregar siphash en la lista.

Para tu información:

Me inspiré en el enfoque de XXHash y usé algo similar en mi propio proyecto/biblioteca (lo llamé RiskyHash ; puede encontrar el código fuente aquí ).

POR CIERTO:

Cuanto más leo, menos me impresiona la necesidad de "seguridad" de la función Hash en lo que respecta a Hash Maps. En mi humilde opinión, la implementación de Hash Map debería manejar las preocupaciones de seguridad, no la función Hashing. Siguiendo esta lógica, el uso de una función Hashing más rápida podría aumentar significativamente el rendimiento.

Sí, en mi opinión, SipHash es excesivo. Incluso con la variante 1-3 "rápida", su rendimiento es menos de la mitad del XXH32.

Solo necesitas un hash decente:

1. El hachís debe ser semillero. Cualquier hash no sembrado se puede precalcular. Los hashes tienen un número virtualmente infinito de colisiones, así de fácil es encontrarlos.
2. Sin colisiones independientes de semillas. El incidente de MurmurHash fue un gran problema porque podía generar fácilmente valores que colisionarían, independientemente de la clave. Da igual la semilla que uses, ese hachís está jodido.
3. Debe tener buena distribución. Esto asegura que los cubos se llenen de manera uniforme y permite cambiar el tamaño a una potencia de 2 y evitar un módulo.
4. Debe ser rápido. El objetivo de una tabla hash es ser lo más rápido posible. Si está gastando 64 ciclos por byte, ¿por qué molestarse?

Se agregó siphash a
https://github.com/Cyan4973/xxHash/wiki/Comparación de rendimiento