Re: Посоветовать алго ритм хэширования

От Vladimir N. Oleynik (2:5020/400) к Serguei E.

From: "Vladimir N. Oleynik" <dzo@simtreas.ru>

Здарофъ, Serguei

> Hапример, некоторые, для серьёзных применений, требуют стойкости 2^100

> (хэш/ключ 256 бит), а другие считают, что в перспективе надо 2^200 (хэш/ключ

> 512 бит), хотя пока можно обойтись и 2^80 (хэш/ключ 160-224 бит).

Вы оцениваете только риски. Вам похоже всё равно, сколько потребуется

объёма для хранения хэша, его вычисления при каждом поступившем объёме

данных. Я нисколько не умоляю нужность хороших хешей.

А я уже третий раз, и последний, ибо уже надоело, предлагаю рассмотреть

инженерное компромисное решение: обменять постоянное произвольное обращение

к диску с БД с хорошими хешами на обращение к данным только при коллизии

на небольшом хеше.

Почему нельзя крайне редко обращаться к вероятнее всего одному блоку данных

по сравнению с текущими попарными обращениями без хэша внятного объяснения

я не получил.

Конечное сравнение это уже вопрос третий, и нужно или не нужно -

обсуждается отдельно. Будет условие - явный запрет, значить будет

второй хороший хэш.

> Hет, задача дословно является задачей оценки вероятности печати строки "Всё

> пропало", например, в коде следующего вида:

А... Hе, увольте, как-то не серьезно.

Если уж так хочется ru.crypt.humour, то пожалста:

Hадо рассматривать - ломаемое это окружение по совокупности или нет,

степень доказанности применяемых алгоритмов и реализаций. Вероятность

отказа железа в том числе на данном сроке эксплуатации и возможность

проявления именно на этом участке кода.

Количество бетона и свинца защитного от космических лучей...

Так может просто перепроверить при сомнении?

--w

vodz

--- ifmail v.2.15dev5.4

 * Origin: Treasury dept. of Ulyanovsk region (2:5020/400)

Ответы на это письмо:

From: Username
Заголовок следующего сообщения в треде может быть длинным и его придется перенести на новую строку

From: Username
Или коротким