On 2007.06.22 at 10:49:58 +0400, Ed wrote: > > я контролирую и отправителя и получателя. > > данные несекретные, шифровать их особого смысла нет. но получатель > должен убедиться, что данные отправил действительно отправитель. > > чем плохо поступить так - заранее сгенерировать ключ (просто > последовательность байт), далее приписываем этот ключ к сообщению и > генерируем для пары сообщение+ключ хэш (тот же sha1). передаем сообщение > + хэш - зная ключ мы легко можем проверить подлинность сообщения.
Это частный случай MAC - message authentication code. Реально используемые MAC-и практически всегда базируются именно на хэшах. Называется HMAC. Рекомендую ознакомиться с описанием алгоритма HMAC, там сделано чуточку похитрее, чем просто дописывание ключа к сообщению. И в rfc2104 слегка объясняется почему делается именно так. Причем HMAC настолько распространен, что многие разработчики криптографического софта вообще не в курсе, что бывают MAC-алгоритмы, базирующиеся не на хэш-функции, например ГОСТ 28147-89 в режиме имитовставки. > из минусов пока вижу только необходимость безопасно доставить ключ на > обе стороны - но в данном случае это проблемы не представляет. Это во многих случаях проблем не представляет. Например, в протоколе TLS(SSL) где каждая запись защищается MAC-ом всё равно вырабатывается общий секрет для шифрования. Поэтому ничто не мешает нагенерить секрета побольше, и использовать его часть для MAC. Еще MAC-ом очень часто защищаются шифрованные сообщения. Потому что нужен какой-то способ убедиться в корректности расшифрования. Соответственно, считаем MAC на симметричном ключе шифрования и дописываем к сообщению. Если при расшифрвании использован правильный ключ, MAC посчитанный на нем после расшифрования совпадет. > а с точки зрения криптостойкости - хуже этот вариант обычной подписи Тем что секрет знают двое. Поэтому не обладает свойством неотрекаемости. Т.е. получатель сообщения не может предъявить третьему лицу (судье) это сообщение и утверждать, что подписал его именно отправитель. Ведь у него самого была полная возможность это сообщение сгенерировать. > (afaik формируем хэш и шифруем его)? Это - не совсем верно. Шифруют хэш только в алгоритме RSA. В алгоритмах на базе схемы Эль-Гамаля (DSA, ECDSA, ГОСТ Р 34.10) происходит не (обратимое) шифрование. Там делается необратимое преобразование исходного сообщения (т.е. хэша), да ешё и с подмешиванием случайного числа. Просто существует такая последовательность арифметических операций, которая позволяет убедиться что данный хэш соответствует данной подписи. А вот имея только подпись и открытый ключ, узнать хэш исходного сообщения нельзя. > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
