Xxhash: 벤치마크에 SipHash 추가...?

물론, 좋은 제안입니다.

siphash 는 이식 가능하며(내 생각에는) 이것이 비교할 수 있는 주요 요구 사항입니다.
기본 판매 포인트는 충돌 생성과 관련하여 향상된 암호화 보호 기능을 제공하지만 원시 속도에서는 불리하다고 생각합니다.

하지만 이를 위한 새로운 벤치마크 플랫폼을 구축할 시간을 찾아야 합니다.

사실, 이 SMHasher fork 에서 몇 가지 초기 테스트를 찾았습니다. xxHash는 작은 입력의 경우 최소 두 배, 긴 입력의 경우 훨씬 빠릅니다.

하지만, 이 정도면 충분하지 않을 것 같아요...

[SipHash의] 주요 판매 포인트는 충돌 생성과 관련하여 향상된 암호화 보호 기능을 제공한다는 것입니다.

특히 홍수 해싱 공격과 관련된 위험 때문에 이것이 내가 깨달았던 것보다 더 큰 요구 사항이라고 생각합니다(이 글을 읽는 다른 사람을 위해 여기에 높은 수준의 설명 과 더 자세한 설명이 있습니다).

요청 시 충돌을 생성할 수 있음을 나타내는 이 스레드 를 찾았습니다.

이 약점을 사용하여 다중 충돌을 생성하고 해시 플러딩 공격으로 이어지는 것이 가능한지 모르겠습니다... 하지만 충돌 생성에 대한 저항은 광범위한 채택을 위한 요구 사항으로 간주되어야 한다고 생각합니다.

...

보안 관련 참고 사항으로 메시지의 처음 32바이트를 특정 값으로 설정하면 모든 벡터는 첫 번째 라운드 이후의 시드와 동일합니다.

이것은 시드 데이터를 추출하거나 해시를 손상시키는 데 악용될 수 있습니다. 나는 이것을 방지하기 위해 되돌릴 수 없는 조작을 사용하는 나만의 변형을 가지고 놀고 있습니다.

다음 xxHash 릴리스에 대한 새로운 벤치마크를 만들 예정이므로 목록에 siphash 를 추가할 수도 있습니다.

참고로:

나는 XXHash의 접근 방식에서 영감을 받아 내 프로젝트/라이브러리에서 비슷한 것을 사용했습니다(저는 이름을 RiskyHash 로 지정했습니다. 소스 코드는 여기에서 찾을 수 있습니다).

BTW:

읽을수록 해시 맵과 관련된 해시 기능 "보안"이 필요하다는 인상을 덜 받습니다. IMHO, 해시 맵 구현은 해싱 기능이 아니라 보안 문제를 처리해야 합니다. 이 논리에 따라 더 빠른 해싱 기능을 사용하면 상당한 성능 향상을 추가할 수 있습니다.

예, IMO, SipHash는 과잉입니다. "빠른" 1-3 변형을 사용하더라도 성능은 XXH32의 절반 미만입니다.

적절한 해시만 있으면 됩니다.

1. 해시는 시드 가능해야 합니다. 시드되지 않은 해시는 미리 계산할 수 있습니다. 해시에는 거의 무한한 수의 충돌이 있습니다. 해시를 찾는 것이 얼마나 쉬운지 알 수 있습니다.
2. 시드 독립 충돌이 없습니다. MurmurHash 사건은 키에 상관없이 충돌할 값을 쉽게 생성할 수 있었기 때문에 큰 문제였습니다. 어떤 시드를 사용하든 상관없이 해시는 망할 것입니다.
3. 분포가 좋아야 합니다. 이렇게 하면 버킷이 고르게 채워지고 2의 거듭제곱으로 크기를 조정하고 모듈러스를 피할 수 있습니다.
4. 빨라야 합니다. 해시 테이블의 요점은 최대한 빨리 하는 것입니다. 64주기를 바이트로 사용하고 있다면 왜 귀찮게 할까요?

에 siphash를 추가했습니다.
https://github.com/Cyan4973/xxHash/wiki/Performance-comparison