Вот и конец MD5

> Разницы между сверкой контрольных сумм и проверки ЭЦП вроде бы нету.

Есть. Помимо всего прочего, ЭЦП призвана удостоверять источник. Если A передал B свой публичный ключ по trusted каналу, то потом он может спокойно передавать данные и ЭЦП по untrusted каналу. Хэш же всего-лишь удостоверяет, что данные не побились при передаче. Не более того. Если злоумышленник ломанёт сайт, то наряду с данными он может фальсифицировать и хэш. И никаких коллизий искть не надо.

по ходу надо менять login, passwd... ?

> по ходу надо менять login, passwd... ?

Это ты про что?

это про переход на blowfish например... вообщем на другой алгоритм как перейти?

>> Разницы между сверкой контрольных сумм и проверки ЭЦП вроде бы нету.

> Есть. Помимо всего прочего, ЭЦП призвана удостоверять источник. Если A передал B свой публичный ключ по trusted каналу, то потом он может спокойно передавать данные и ЭЦП по untrusted каналу. Хэш же всего-лишь удостоверяет, что данные не побились при передаче. Не более того. Если злоумышленник ломанёт сайт, то наряду с данными он может фальсифицировать и хэш. И никаких коллизий искть не надо.

Для случая использования контрольной суммы мы проверяем равенство hash(x)==hash(x').

Для случая же использования ЭЦП (ЭЦП=priv_key(hash(x))) мы проверяем, что pub_key(ЭЦП)==hash(x'), а т.к. pub_key(priv_key(z))==z, то мы проверяем всё то же равенство hash(x)==hash(x').

Стойкость преобразований pub_key и priv_key - это отдельная история, о которой сейчас речь не идёт.

> мы проверяем всё то же равенство hash(x)==hash(x').

Мы ещё проверяем, что подписано было именно тем priv_key, которым нужно. Достоверность такой проверки зависит от криптостойкости алгоритма и секретности priv_key.

Скажем так, если у меня есть возможность злонамеренно заменить некоторое файло вместе с контрольной информацией, то если контрольная информация - просто хэш, то мне не нужно больше ничего для введения получателей информации в заблуждение. Если же информация _подписана_, то я не могу правильно подписать свою злонамеренную информацию, не узнав priv_key, а это уже совсем другая песня.

> Мы ещё проверяем, что подписано было именно тем priv_key, которым нужно. Достоверность такой проверки зависит от криптостойкости алгоритма и секретности priv_key.

не понял.. AFAIK электронной подписью подписывается хэш. То есть если человек сделал файл, его подписал -- это значит что он подписал его хэш. Здоумышленник сделал другой файл с тем же хэшом, то подпись справедлива и для него. Это цепочка. В ней ломается самое слабое на сегодня звено -- хэш.

> AFAIK электронной подписью подписывается хэш.

На самом деле, если передаётся шифрованный контент от A к B, то вместо передачи pub_key_b(data) и подписи, можно передавать pub_key_b(priv_key_a(data)). Тогда подпись будет встроена в сам документ :)

> AFAIK электронной подписью подписывается хэш

Ага, понял... :) Мы говорим о разных вещах. Всё началось с того, что кто-то тут заявил, что хэш и ЭЦП - суть одно и то же, хотя это не так. Да, хэш-функции применяются в ЭЦП как составная часть, но это далеко не единственная, и даже наверно, не основная составляющая.

watashiwa_daredeska, ты не понимаешь.

Если мы сумеем найти поддельный файл x' такой, что hash(x)==hash(x'), то ЭЦП для файла x будет совпадать с ЭЦП для файла x'.

Т.е. можно подменить файл x на x' даже без знания priv_key.

> Всё началось с того, что кто-то тут заявил, что хэш и ЭЦП - суть одно и то же, хотя это не так. Да, хэш-функции применяются в ЭЦП как составная часть, но это далеко не единственная, и даже наверно, не основная составляющая.

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

>Если A передал B свой публичный ключ по trusted каналу
А зачем передавать ПУБЛИЧНЫЙ ключ по trusted каналу ???

>А зачем передавать ПУБЛИЧНЫЙ ключ по trusted каналу ??? Чтоб исключить "Man in the middle"