64 비트의 SHA1 해시 만 ID로 사용 하시겠습니까?

Question

1) 실제로 낮은 해시 충돌을 목적으로, SHA1 자체를 다루지 않고 128 비트의 SHA1의 절반을 사용하여 도망 갈 수 있습니까? 나는 이것이 암호화 해시에 적합하지 않다는 것을 이해하지만 해시 테이블 키에는 해시 만 있으면됩니다.

2) 계산 시간은 우선 순위가 아니며, 그 외에도 매우 작은 데이터를 해시합니다. 특히, 나는 주로 2 또는 3 64 비트 해시를 복용하고 다른 64 비트 해시를 얻기 위해 해시를 할 것입니다. 이 목적을 위해 SHA1보다 더 나은 옵션이 있습니까? 다시, 충돌은 거의 가능하지 않아야합니다.

3) 저는 SQL Newb입니다. SQL에서 64 비트 해시를 ID로 사용하는 것이 좋은 생각입니까? 64 비트 ID의 SQLite 또는 Postgr에서 성능 문제가 발생합니까? 여러 데이터베이스 (Lucene Index 포함)에서 데이터를 조정해야하므로 자동 증가 된 ID로 귀찮게하지 않고 테이블에서 해시를 직접 처리해야한다고 생각했습니다 (하나의 DB에서만 의미가 없을 것입니다. 모든 데이터 저장소에서). 그림 64 비트는 좋은 타협입니다. 충돌은 거의 없지만 공간을 절약 할 수는 없습니다 (및 조회 시간).

4) CRC-64는 어떻습니까? 그것은 충분한 분포를 생성합니까?

Answer 1

충분한 레코드가 없다면 64 비트로 해시 충돌을받지 않을 것입니다. 아마도 당신은이 범주에 속할 것입니다.

거기 ~해야 한다 해시에 내부 구조가 있으면 암호화 해시가되기에 충분하지 않기 때문에 SHA1과 같은 암호화 해시를 다듬는 데 아무런 문제가 없습니다. . 나는 암호화 목적이 아니라 ID에 그것을 사용하는 것에 대해서만 이야기하고 있습니다!

그러나 실제로, 당신의 SQL에는 일종의지도가 없습니까? 그렇다면 왜 사용하지 않습니까?

Answer 2

해시 길이를 잘 비교하려면 http://en.wikipedia.org/wiki/list_of_hash_functions

또한, 단지 참고 : SHA-1은 128이 아닌 160 비트입니다.

Answer 3

당신의 열쇠는 고유성의 확률이 높지 않은 절대적인 독창성이 필요합니다. 교차-다베이스 호환성을 위해 키에 해시 대신 안내를 사용하는 것이 좋습니다. 해시를 빠른 조회 메커니즘으로 생성하십시오. 이에 대한 비 유니크 인덱스를 가질 수 있지만 충돌의 경우 실제 데이터를 비교하여 동일한 지 확인해야합니다. 데이터베이스를 동기화 할 때 해시 (색인 사용)를 확인하고 충돌을 찾으면 데이터가 동일하고 안내서를 해결해야합니다. 충돌이 없으면 누락 된 항목이 필요한 데이터베이스를 업데이트하고 다른 데이터베이스의 Guid를 사용하여 삽입하십시오.

나도 공간을 절약하기 위해 자신의 해시 해시 해시를 만드는 데 거의 요점을 보게됩니다. 이미 다른 해시가 있다면 사용하십시오 (추가하지 말고 다시 해쉬하지 마십시오). 그렇지 않은 경우 MD5 또는 SHA1과 같은 표준 해시 기능을 사용하고 결과 데이터를 저장하십시오.

Answer 4

64 비트 해시를 사용하면 6.1 × 10과 충돌 할 확률이 1%입니다.⁸ 기록. (다른 조합은 Wikipedia를 참조하십시오 생일 문제의 페이지.) 처음 64 비트 또는 마지막 비트의 마지막 64 비트를 버릴 수 있습니다. 해시의 특성과는 차이가 없습니다.

Answer 5

계산 시간이 중요하지 않은 경우 128 비트 전체를 가십시오. 가능한 스토리지 문제 외에 64 비트를 선택해야 할 실제 이유가 있습니까? (그리고 여분의 8 바이트가 저장으로 저렴하게 당신을 죽이지 않을 것입니다)

64 비트 vs 128 비트는 SQLite에서 속도 문제를 일으키지 않습니다. MySQL에 대해서는 확실하지 않습니다.