이 솔루션과의 해시 충돌을 피할 수 있습니까?

Question

페이지에 textarea 요소가 있으며 작성한 저장 버튼을 클릭하면 내용이 내 데이터베이스에 저장됩니다. 나는 "MySite.com/laHquq"와 같은 해쉬 ID를 사용하여 텍스트 영역에있는 정보를 포함하는 내 레코드를 저장 한 테이블 행의 고유 ID (기본 키)와 다음을 사용하여 단축 URL을 만들고 싶습니다. http://www.hashids.org/ "Generate (YouTube와 Bitly와 같은) 숫자의 짧은 해시. " 텍스트 영역의 정보가 들어있는 레코드가있는 테이블 행의 고유 기본 키를 난독 화하기 위해이 키를 사용하려고합니다.

주소 표시 줄에 내 도메인 이름의 끝에 슬래시를 사용하여 만들어진 해시 ID (기본 키를 난독 화하는)를 스크립트에 넣으려고하면 주소 표시 줄에 "MySite .com/laHquq "정보가 내 데이터베이스에 저장된 후. 이것은 단순히 텍스트 영역에 저장된 정보가 슬래시 뒤에 해쉬 아이디가있는 사이트를 방문하여 다시 볼 수 있음을 나타 내기 위해 수행됩니다.

페이지가로드 될 때마다 주소 표시 줄에서 URL을 가져 와서 슬래시 다음에 해시 ID를 확인한 후 해시 ID를 사용하여 올바른 정보를 찾는 스크립트를 자체 호출 기능과 함께 사용합니다. 페이지의 텍스트 영역에 표시 할 db입니다. hashids를 사용하는 것이 궁금합니다 : http://www.hashids.org/은 해시 충돌을 방지하는 데 도움이됩니다.

Answer 1

설명서를 보면 해시드와의 충돌이 발생하지 않을 것 같습니다. 그것은 해시가 아니기 때문입니다. 그것은 암호 - 암호화 알고리즘입니다. 정말 약하지만 해시처럼 보이는 ID를 생성하기에 충분합니다.

한 가지 중요한 단서는 decrypt 기능이 있다는 것입니다. 실제 해시, 즉 충돌 할 수있는 해시는 동일한 해시를 생성하는 여러 값 (대개 무한)이 있기 때문에 단일 값으로 해독 할 수 없습니다.

몇 가지면에서 Base64 인코딩과 비슷하지만 문자 세트는 URL 유형 (예 : + 또는 /)으로 선택되었습니다.

Answer 2

PHP로 경험적 결과를 여기에 표시합니다. 아래와 같이 우리는이 소금 5 개 문자의 최소, 테스트 : 1에서 PK를 해싱, MySQL의 DB에 행을 채우기 위해 루프에서 일주일 동안 24 시간 연중 무휴를 실행하는 과정을 통해

$hashids = new Hashids\Hashids('this is my salt', 5, 'BCDFGHJKLMNPQRSTVWXYZ'); 

A의, 이 같은 테이블 : UNIQUE 해시 인덱스 및 제어 모두 스크립트 동안 ON DUPLICATE 키 및 온 전성 검사에 대한 프로세스의 마지막에 SELECT DISTINCT를 실행하는

create table hashids (
    id int NOT NULL AUTO_INCREMENT primary key, 
    hash varchar(255) 
); 

.

우리는 그 다음 우리가 서명 BIGINT의 상한에 가까운부터 시작하기로 결정

select count(*) from hashids; 
+-----------+ 
| count(*) | 
+-----------+ 
| 355325777 | 
+-----------+ 

에 과정을 중단했다.

ID: 9223372036854775000-> HASH: RQ0ZPNPPPZ6Q7RNV 
ID: 9223372036854775329-> HASH: YN2K8Y888K7NW6VY 
ID: 9223372036854775654-> HASH: 2MQ0474440VM8QMY 
ID: 9223372036854775777-> HASH: 7L25R7RRR5ZL820W 
ID: 9223372036854775805-> HASH: 020WV7VVVWX250YM 
ID: 9223372036854775807-> HASH: QVMZYRYYYZXVLM0W 

두 경우 모두 며칠 째 실행하고 15Gb의 ID를 채운 후 해시드는 서있었습니다.

지금까지 충돌을 확인했습니다.

이 테스트는 우리 어플리케이션의 한계를 뛰어 넘기 때문에 우리는 Hashids가 우리에게 안전하다고 생각했습니다. 물론 수학에서와 마찬가지로 경험적 결과는 법을 증명하지 못합니다.

또한 Hashids는 서명 된/서명되지 않은 BIGINT MySQL DB 제한 또는 PHP_INT_MAX에 도달하기 전에 적어도 PHP에 대한 상한선이 있음을 기억하십시오.