Re: чем плоха подпись с помощью хэш-функции?
взять книгу Шнайера Прикладная криптография и прочитать там всё, что про MAC и HMAC написано. Дабы представлять себе ограничения применимости решений на их базе. +1 Отличнейшая книга, присоединяюсь к совету. Правдо в своей второй(?) книге он указал на массу её недостатков, но это отнюдь не умаляет её достоинств. Он не недостатки ее указал, а границы применимости. Не надо путать :-)
Re: чем плоха подпись с помощью хэш-функции?
On 2007.06.22 at 20:02:58 +0400, Ed wrote: меня вполне устраивает то, что никто кроме этих двух не мог сгенерировать это сообщение подводя итог - HMAC хороший выбор? или смотреть на что-то другое? на что тогда? Вполне приемлимый. TLS его используует, OpenVPN использует, и ещё много кто использует. Но рекомендуется всё же сначала взять книгу Шнайера Прикладная криптография и прочитать там всё, что про MAC и HMAC написано. Дабы представлять себе ограничения применимости решений на их базе. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: чем плоха подпись с помощью хэш-функции?
В сообщении от 22 Июнь 2007 10:49 Ed написал(a): схема: отправитель - небезопасный канал (интернет) - получатель я контролирую и отправителя и получателя. данные несекретные, шифровать их особого смысла нет. но получатель должен убедиться, что данные отправил действительно отправитель. чем плохо поступить так - заранее сгенерировать ключ (просто последовательность байт), далее приписываем этот ключ к сообщению и генерируем для пары сообщение+ключ хэш (тот же sha1). передаем сообщение + хэш - зная ключ мы легко можем проверить подлинность сообщения. Ну и правильно. Получается, что ключ у тебя в открытом виде передается, враг берет вставляет свое сообщение, приделывает этот же ключ и генерирует по такому же алгоритму хэш. А теперь пойми где подделка. плюсы - легко в реализации, низкая вычислительная сложность, минимальное увеличение размера передаваемой информации. из минусов пока вижу только необходимость безопасно доставить ключ на обе стороны - но в данном случае это проблемы не представляет. Главный минус - это то, что ключ знают и тот, кто передает, и тот, кто получает, и тот, кто подделывает. Количество информации такого ключа по Шеннону равно нулю, а значит он просто отнимает байты от пропускной способности - это его второй минус. а с точки зрения криптостойкости - хуже этот вариант обычной подписи (afaik формируем хэш и шифруем его)? Фишка в ЭЦП - ключи ассиметричные. -- Макс -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: чем плоха подпись с помощью хэш-функции?
Twas brillig at 11:11:44 22.06.2007 UTC+04 when Max Dmitrichenko did gyre and gimble: MD Ну и правильно. Получается, что ключ у тебя в открытом виде передается, MD враг берет вставляет свое сообщение, приделывает этот же ключ и генерирует MD по такому же алгоритму хэш. А теперь пойми где подделка. Как я понял, передаётся оригинальное сообщение плюс подпись оригинал+ключ. -- JID: [EMAIL PROTECTED]
Re: чем плоха подпись с помощью хэш-функции?
В сообщении от 22 Июнь 2007 11:15 Mikhail Gusarov написал(a): Twas brillig at 11:11:44 22.06.2007 UTC+04 when Max Dmitrichenko did gyre and gimble: MD Ну и правильно. Получается, что ключ у тебя в открытом виде передается, MD враг берет вставляет свое сообщение, приделывает этот же ключ и генерирует MD по такому же алгоритму хэш. А теперь пойми где подделка. Как я понял, передаётся оригинальное сообщение плюс подпись оригинал+ключ. Даже если так, то получается, что реципиент может создавать сообщения от имени автора. Что в общем не универсально, поскольку необходимость уверено получать сообщения от всех абонентов возникает чаще, чем уверено получать сообщения от абонента, который безусловно доверяет тебе (свой ключ). Кроме того, схема с несимметричным ключом _тоже_ _требует_ доставки публичного ключа другим защищенным каналом. (Или хотя бы отпечатка ключа). В общем случае используется система распространения ключей, используя центр распространения ключей. В этом случае все абоненты получают публичные ключи других абонентов по требованию по обычному каналу, но сам публичный ключ подписан ключом центра распространения ключей, который (предполагается) есть у всех абонентов ЦРК. И ещё: если у тебя паранойя - это вовсе не значит, что за тобой не следят :) -- Макс -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: чем плоха подпись с помощью хэш-функции?
В сообщении от 22 Июнь 2007 11:29 Ed написал(a): Max Dmitrichenko wrote: Ну и правильно. Получается, что ключ у тебя в открытом виде передается, враг берет вставляет свое сообщение, приделывает этот же ключ и генерирует по такому же алгоритму хэш. А теперь пойми где подделка. я конечно идиот, но не настолько. передается сообщение + хэш(сообщение+ключ) Сорри, но вот эта фраза сбила меня с толку: далее приписываем этот ключ к сообщению Но все равно схема не секьюрна - читай соседний тред. -- Макс -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: чем плоха подпись с помощью хэш-функции?
On 6/22/07, Mikhail Gusarov [EMAIL PROTECTED] wrote: Twas brillig at 11:11:44 22.06.2007 UTC+04 when Max Dmitrichenko did gyre and gimble: MD Ну и правильно. Получается, что ключ у тебя в открытом виде передается, MD враг берет вставляет свое сообщение, приделывает этот же ключ и генерирует MD по такому же алгоритму хэш. А теперь пойми где подделка. Как я понял, передаётся оригинальное сообщение плюс подпись оригинал+ключ. По-моему, метод нестоек в отношении коллизий используемой хэш-функции. -- С уважением, Константин Матюхин
Re: чем плоха подпись с помощью хэш-функции?
Max Dmitrichenko wrote: Даже если так, то получается, что реципиент может создавать сообщения от имени автора. Что в общем не универсально, поскольку необходимость уверено получать сообщения от всех абонентов возникает чаще, чем уверено получать сообщения от абонента, который безусловно доверяет тебе (свой ключ). мне и не нужна универсальная схема. у меня есть сервер (мой) и куча железок (опять же моих), которые обмениваются информацией. залить ключ при прошивке железки проблемы не представляет. в принципе на железке будет обычный linux, можно воспользоваться и openssl и стандартными алгоритмами - но если можно сделать проще - почему бы и нет? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: чем плоха подпись с помощью хэш-функции?
On Fri, Jun 22, 2007 at 10:49:58AM +0400, Ed wrote: из минусов пока вижу только необходимость безопасно доставить ключ на обе стороны - но в данном случае это проблемы не представляет. а с точки зрения криптостойкости - хуже этот вариант обычной подписи (afaik формируем хэш и шифруем его)? Для одноразового ключа и большого количества сообщений IMHO хуже. С каждым перехваченным сообщением ключ становится все более уязвим. Если сообщения открыты -- особенно. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: чем плоха подпись с помощью хэш-функции?
В сообщении от 22 Июнь 2007 14:28 Иван Лох написал(a): On Fri, Jun 22, 2007 at 10:49:58AM +0400, Ed wrote: из минусов пока вижу только необходимость безопасно доставить ключ на обе стороны - но в данном случае это проблемы не представляет. а с точки зрения криптостойкости - хуже этот вариант обычной подписи (afaik формируем хэш и шифруем его)? Для одноразового ключа и большого количества сообщений IMHO хуже. С каждым перехваченным сообщением ключ становится все более уязвим. Если сообщения открыты -- особенно. Ну тут можно генерировать новый ключ на основе старого. Скажем, через каждые n сообщений. Алгоритм, естественно, должен быть известен обеим сторонам. -- Макс -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: чем плоха подпись с помощью хэш-функции?
On Fri, Jun 22, 2007 at 03:20:42PM +0400, Max Dmitrichenko wrote: В сообщении от 22 Июнь 2007 14:28 Иван Лох написал(a): On Fri, Jun 22, 2007 at 10:49:58AM +0400, Ed wrote: Для одноразового ключа и большого количества сообщений IMHO хуже. С каждым перехваченным сообщением ключ становится все более уязвим. Если сообщения открыты -- особенно. Ну тут можно генерировать новый ключ на основе старого. Скажем, через каждые n сообщений. Алгоритм, естественно, должен быть известен обеим сторонам. Генерировать можно, конечно. Только алгоритм, по-хорошему, должен сводиться к генератору случайных чисел. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: чем плоха подпись с помощью хэш-функции?
Фигурный subject. Это интересно у меня evo чудит или kmail и так кодировать не положено? -- Alexander Vlasov ZULU-UANIC JID: zulu at jabber.kiev.ua -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: чем плоха подпись с помощью хэш-функции?
Fri, 22 Jun 2007 10:49:58 +0400, Ed [EMAIL PROTECTED]: схема: отправитель - небезопасный канал (интернет) - получатель я контролирую и отправителя и получателя. данные несекретные, шифровать их особого смысла нет. но получатель должен убедиться, что данные отправил действительно отправитель. чем плохо поступить так - заранее сгенерировать ключ (просто последовательность байт), далее приписываем этот ключ к сообщению и генерируем для пары сообщение+ключ хэш (тот же sha1). передаем сообщение + хэш - зная ключ мы легко можем проверить подлинность сообщения. Как я понимаю, у Вас есть надёжный способ передать секретный ключ получателю и обеспечить его секретность. В этом случае вообще можно наладить полностью секретный канал между отправителем и получателем средствами симметричного шифрования, и считать всё, полученное по этому каналу, «надёжным». Необходимость в подписях в этом случае отпадает. Как и в Вашем предложении, использовать такую систему для подтверждения авторства (цифровой подписи) -- невозможно, так как ключ подписи известен как минимум двум сторонам, и подписывать могут обе. Отвечу на вопрос, почему плохо поступить так, как предлагаете Вы: 1) функции цифровой подписи такая система не выполняет, см. выше; 2) созданный Вами лично алгоритм защиты не пройдёт должного анализа и не будет открыто обсуждаться; уязвимости и особенности широко использованных алгоритмов широко обсуждаются и обычно известны; практика применения «самодельных» криптосистем показывает их ненадёжность; опять же, особенности работу разных хэш-функций, могут сильно влиять на результат. 3) «самодельные» реализации даже известных и проверенных алгоритмов более подвержены ошибкам и уязвимостям, так как никто не будет проверять, насколько правильно и осмотрительно вы реализовали алгоритм. 4) зачем изобретать велосипед? выберите любую уже проверенную систему цифровой подписи, широко используемую библиотеку с её реализацией и пользуйтесь на здоровье.
Re: чем плоха подпись с помощью хэш-функции?
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]
Re: чем плоха подпись с помощью хэш-функции?
jetxee wrote: В этом случае вообще можно наладить полностью секретный канал между отправителем и получателем средствами симметричного шифрования, и считать всё, полученное по этому каналу, «надёжным». Необходимость в подписях в этом случае отпадает. по размышлению мне этот вариант нравится всё больше. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
