Хэш-функция PHP с большой длиной вывода? - PullRequest
3 голосов
/ 17 ноября 2008

Внутри моего кода я генерирую хеши URL (которые практически неограниченной длины). В настоящее время я использую sha1 (), который, как я знаю, имеет малую вероятность коллизии, но у меня есть до 255 байтов для хранения хэша, поэтому чувствую, что я мог бы также использовать это доступное пространство, чтобы снизить вероятность коллизии дополнительно.

Есть ли:

  1. Еще одна PHP-хеш-функция с более длинной или настраиваемой длиной хеш-функции?
  2. Способ использования хеш-функции фиксированной длины, такой как sha1, с вводом переменной длины для создания более длинного хеша?

Или 20-байтовый хэш sha1 достаточно хорош для чего-либо, и я должен перестать беспокоиться об этом?

Ответы [ 7 ]

5 голосов
/ 17 ноября 2008

Или 20-байтовый код sha1 достаточно хорош для чего-либо, и я должен перестать беспокоиться об этом?

Точно.

Hashtables, Pigeonholes и дни рождения
http://www.codinghorror.com/blog/archives/001014.html

3 голосов
/ 17 ноября 2008

Давай посмотрим ... http://www.cryptography.com/cnews/hash.html

Q: Как трудно было бы найти столкновения в SHA-1?
A: сообщили атаки требуют сметной работы коэффициент 2 ^ 69 (примерно 590 миллиард миллиардов) хэш-вычислений

Похоже, риск довольно низкий ... ^ _ ^

1 голос
/ 17 ноября 2008

Если вы действительно беспокоитесь, выберите 256- или 512-битный хеш (32 или 64 символа).

Если вы действительно параноик, добавьте соль.

Если вы более параноидальны, объедините два хэша для более длинного, такого как md5 и sha-256.

0 голосов
/ 25 июля 2009

Ну, это имеет смысл, только если у вас есть ключ хеша ашорта. В противном случае существует риск переполнения данных в таблице.

0 голосов
/ 17 ноября 2008

если вы хотите по-настоящему сойти с ума, то вы можете объединить хэши различных частей URL.

Скажем, URL имеет длину 40 символов - разбейте его на 5 частей: получите SHA1 из символов 1-8, объедините их с SHA1 из символов 9-16, объедините с SHA1 из 17-24 ... и т. Д. Теоретически тогда у вас будет 2 800 возможностей, и вам нужно будет начать беспокоиться о столкновениях только после 2 (69 * 5) = 2 345 = 7,2 * 10 103 строк.

но, как я уже сказал, мы направляемся прямо в сумасшедший город такими методами.

0 голосов
/ 17 ноября 2008

Поскольку я не знаю точно, что вы пытаетесь сделать, я сделаю предположение, что вы не хотите вводить данные дважды и хотите быстро обнаруживать столкновения. В этом случае я предлагаю следующий алгоритм в псевдокоде:

found = false
hv = hash(urlValue)
if table[hash,url] contains pair (hv,urlValue)
   found = true
endif

if (not found)
   insert table (hv,urlValue)
endif

В вашей базе данных создайте неуникальный индекс для столбца хеша, чтобы ускорить поиск. Это позволит быстро выполнить запрос по (hash, url) - в обычном случае вы смотрите только на одну строку, поскольку хэш, вероятно, уникален, но вы действительно решаете принять или отклонить на основе фактического URL. Это позволит вам использовать более короткую хеш-функцию. Предположительно, вы уже сохраняете URL для последующего использования, поэтому это не потребует дополнительного хранилища.

0 голосов
/ 17 ноября 2008

Вы всегда можете добавить / добавить последовательный идентификатор (в десятичном или шестнадцатеричном виде) к существующему хешу?

Конечно, у вас не было бы хэша фиксированной длины, но вы знали бы, что код был а) уникальным и б) не угадываемым (даже если бы кто-то заметил последовательную часть, он не знал бы, как вы солили / хешировали остальной код).

Конечно, если вы не пытаетесь скрыть эти хэши от кого-либо, то почему бы просто не использовать последовательный идентификатор в первую очередь?

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...