> > (который был впоследствии опровергнут) и патетически
> > вопрошает "Что мы должны думать о ФАПСИ, сознательно
> > оставившем такую дыру?!".
>
> Простите а откуда Вы взяли подобную фразу? Если уж
> цитируете, да ещё с кавычками кавычами, так обеспечьте
> соответствие тексту.
Пожалуйста:
[quote]
В вариант, что разрабатывавшие ГОСТ математики (и проверявшие его криптоаналитики ), решили, что математические ограничения можно вводить законодательно как-то не верится... Что нам остаётся думать???
[/quote]
В прошлом постинге цитировал не дословно, но смысл не исказил, n'est pas? ;)
> ;)) не
> > имеют универсальной подписи, проходящей проверку? Я не
> > говорю о последующем доказательстве ее умышленности...
>
> Нет не имеет. У них подобной подписью может являеться
> только (0,1).
> Такая подпись не пройдёт входных проверок (s>0, r>0).
> Так, что это "достоинство" ГОСТа, вызванное, как правильно
> пишет Комлин "законадательным" введением ограничений.
Ну, если Вам хочется назвать это именно так ;)
Я бы интерпретировал по-другому: описан способ защиты сообщений, заданы условия для этого. При нарушении условий защита не обеспечивается. Отсутствие в описании алгоритма механизмов контроля обусловлено тем, что нарушение может быть только умышленным. При предъявлении претензий нечестный участник обмена будет в этом уличен.
> > А никак. Эта уязвимость возможна только при
> > желании законного владельца секретного ключа
> Х.
> > Не думаю, что кто-то захочет наскрести себе
> неприятностей,
> > особенно после этой дискуссии.
>
> А также в случае когда секретный ключ украден и у вора нет
> времени разбираться с дополнительными методами защиты в
> первую очередь с формированием документа для хэширования.
> (см. ниже.)
Комментарии по поводу "секретной приписки" - также ниже ;)
> Претензия к ФАПСИ не в том, что они заставляют всех
> сертифицироваться, а в том что
>
> 1) У пользователя/разработчика отсуствует возможность
> выбора между методами, как это сделано в DSS.
В каком смысле "методов"? RSA, DSA и EDSA - суть разные алгоритмы. Если существование последних двух - аналог Р3410 94/2001, то нафига RSA - вообще непонятно. И зачем этот зоопарк? Все должно быть как в армии - единообразно ;) Ведь исследование алгоритма занимает порядка 17 человеко-лет...
> 2) Непонятно зачем не доступен ряд документов,позволяющих
> повысить стойкость методов.
Точнее, сделать правильную реализацию. Кстати, такой претензии у Александра нет. Если не считать претензией сам факт появления статьи, появившейся как раз из-за того, что в отличие от DSA в ГОСТ не приведено доказательств/объяснений почему оно все именно так выбрано.
> > компрометации не говорится, умышленная она или нет),
> несет
> > владелец ключа.
>
> Речь идёт о конкретном договоре не так ли? К тому же
Нет, об общем подходе.
> ущемляющим права клиента? Далеко не всякий крупный клиент
> подпишет договор ущемляющий его права. Да и мелкий может
> поискать другой банк.
Рискую показаться грубым, но "с фига ли баня-то упала?" ;))
Вы понимаете, что обмен сообщениями - процесс двусторонний? ЭЦП (ЦП) выдумана как раз для ситуаций, когда участники обмена не доверяют друг другу. У банка тоже есть секретный ключ, и мошенничество с его стороны по отношению к клиенту тоже возможно. Так вот, речь идет о риске компрометации секр. ключа участником обмена. Неважно, банком или клиентом. Где ущемление?
> Мой пример не слишком удачен, особенно в свете
> нижесказанного, но он приводился просто для иллюстрации
> многообразия методов компроментации. Вы ведь тоже привели
> ещё один?
Да, привел. И бороться с ним криптографическими средствами - никак.
Тоже ГОСТ виноват? Как тут не вспомнить анек про поручика Ржевского ;)
> > умышленности (Х,1), когда можно послать нормальную
> подпись
> > с k!=0 (S,r')?
>
> "Просто сформировать" подпись не так-то просто (я уже
Не, ну понятно, что надо знать структуру ключевого носителя, иметь программу формирования ЭЦП, знать формат платежки... Однако, вспомните правило Керкхоффа: криптоаналитик знает все, кроме ключа. Из этого и надо исходить...
> писала это Александру как замечания к способу
> компроментации подписи, теперь Вам :). Использование
> универсальной подписи позволяет элементарно обойти одну из
> самых распрастранённых допзащит: секретная дописка( см.
> ниже) к документу (Та самая комплексная защита). Поэтому
> для злоумышленника логичнее всего использовать именно её.
Гм. Позвольте дать справку ;) Не просто секретная, а одноразовая ;)
Этот механизм называют "одноразовые коды подтверждения достоверности" (КПД), и он не является криптографическим методом защиты. Если к каждой платежке должен быть добавлен уникальный КПД, то хоть с универсальной подписью, хоть с честно ворованным ключом поддельность платежки сразу будет выявлена.
Дополнительно он решает еще проблему, когда надо передать ключ сотруднику фирмы временно. Ведь он может его скопировать, а если ему дать всего 5 очередных КПД, то он отправит не больше 5 платежек и после возврата ключа директору сделать все равно ничего не сможет (ну, выписку разве что получить).
> Даже захватив (сымитировав захват) секретный ключ (
> особенно предлагаемым Владом, путём грабежа оффиса )
Hey! Easy, easy! А то меня еще обвинят в сучастии в форме выдачи советов по приисканию способов совершения ;) А часть вторая (группой лиц по предварительному сговору) предусматривает больший срок ;))
> атакующему стоит разобраться с особенностями формирования
> документа для хэширования. По крайней мере туда включаются
Ой. Я Вас умоляю. Security by obscurity? Сокрытие формата уже давно не считается защитой. Помню, в свое время, на "вскрытие" формата файла игрушки F117 (с целью дописать очки и повысит звание ;)) ушло около получаса ;)
> идентификаторы пользователя, причём они могут и не
> включаться в отсылаемый документ, а подключаться на этапе
> хэширования.
Что тоже выявляемо (несоответствие хеша тексту).
> методы защиты . Как правило речь идёт о том, что перед
> получением хэша документа к нему дописывается некоторый код
> известный только программе/пользователю (в VIP DS паре
> банк-пользователь, причём вводится непосредственно
> пользователем в момент подписи) и разумеется, в отсылаемый
> документ он не дописывается. Это кстати служит и
> прекрасной защитой от прослушивания /подбора (k,r) .
Ага. А еще, что характерно, подписанная платежка перед отправкой в банк имеет подлое свойство шифроваться на открытом ключе банка ;) Соответственно, для прочтения ее (и анализа r' и прочих параметров) злоумышленнику еще надо где-то достать секретный ключ банка ;)
Да, но мы отвлеклись. Речь-то ведь шла о нечестном клиенте? Уж ему-то доступны и формат, и "секретные приставки". Вот только проблематично будет объяснить знание мифическим злоумышленником (даже подобравшим ключ Х по Y) знание этой самой приставки ;)
> Полный анализ чужой программы без исходников дело очень
> долгое и зачастую непосильное, гораздо проще рассмотреть
Ну (сорри, опять же за воспоминания) в свое время по бинарнику еще не то восстанавливали. Отключение дурацких вопросов при загрузке игрушки, отключение привязки средства защиты к определенной ТМ. Да тот же алгоритм шифрования паролей в новеле (ну, не было тогда доступных исходников!) выцарапывался путем трассировки VLM. Решение этой задачи для специалиста - несколько часов максимум. Пару лет назад я наблюдал, как спец выцарапывал из динамически шифрованного тела троянца e-mail, куда этот гад пытался заслать уворованные пароли ;) Времени у него (спеца) это много не отняло...
> структуру пересыламого документа и использовать
> универсальную подпись.
Хм, а структуру отправляемого пакета (сообщение+подпись) ему изучать не надо?
> Поэтому для использования универсальной подписи у
> атакующего причины есть.
С учетом одноразовых кодов или постоянной секретной приставки - сомнительно...
> > Наталья, безопасность - штука комплексная. Не все
> проблемы
> > можно решить математически/криптографически, поэтому
> по
> > использованию ЭЦП и составляют договора. Зачем делать
> при
> > проверке подписи контроль S==X и r'==1? Ну, проверится
> > такая подпись корректно, ну будет она универсальной.
> Зачем
> > проверяющему лишние телодвижения, если он все равно не
> > пострадает?
> О комплексности защиты конечно сказано правильно, но из
> статьи как раз и следует то, что ГОСТ в эту комплексность
> лишние дырки добавляет. Их нетрудно перекрыть (проверкой
Простите, но большинство людей просто честно работает. И лишь некоторые мошенничают. Зачем каждый раз делать излишние проверки, которые можн сделать лишь в случае инцидента?
> Кстати вспомните одно из назначений ЭЦП - она защищает от
> данные от искажения.
> С учётом универсальной подписи, существует по крайней мере
> одно такое искажение, что документ будет принят. Разумеется
> подобная ситуация возможна только только теоритически, но
> в других алгоритмах даже такого нет.
Вы хотите сказать, что документ останется целым, а при передаче подпись случайно исказится до вида (Х,1)? Ну, теоретически возхможно ;) Только вот посылка еще шифруется, и настоящие параноики вычисляют имитовставку. Так что все всплывет при расшифровании...
> Поэтому я считаю себя в праве говорить,что ГОСТ хуже
> одноклассников.
;) А я вправе считать наоборот ;)
> > Да? Не заметил ;)
> HTM -вариант статьи (ссылка в конце сообщения об
> усовершенствованном способе подписи).
нашел ;)
> > единственное место. Почитайте cnews.ru -думаю, многим
> уже
> > стыдно за сказанное.
> Вы о форуме cnews? Читала (пока он был доступен) ,
> единственное что написал Волчков - о несбалансированности
> защиты ГОСТа (абсолютно верно кстати).
А я что-то про Волчкова говорил конкретно? ;)
Насчет "несбалансированности" - был наезд на "кривизну" хэша. Не знаю, что он имел ввиду, но, что характерно, размер хеша совпадает с размером ключа ГОСТ 28147. Не кажется, что это весьма удобно?
> > А еще стоит помнить, что никто не безгрешен: ФАПСИ
> находило
> > ошибки и в продуктах ЛК.
> Ссылочку?
Проблема. Это из устных разговоров, тогда инет еще был слабо развит.
> Насколько я помню речь шла не об ошибках а о несоответствии
> ГОСТу.
А мне помнится, что алгоритм был реализован правильно, но была чисто программистская бага с обработкой последнего блока. Потерзаю знакомого при случае, ибо сам уже слабо помню суть...
> Сертификация- пожалуйста. Только зачем же навязывать свой
> алгоритм да ещё единственный, да ещё уступающий
Время на анализ алгоритма 17 человеко-лет, и не все распараллеливается. Позиция ФАПСИ - сертифицировать только реализации отечественных алгоритмов. Я нахожу ее разумной. Почему-то АНБ (No Such Agency :)) не занимается ГОСТ 28147, а "видит" исключительно AES (DES до недавних времен).
> мало чем грозит. В условиях роста производительности
> компъхютерного парка это (комбинированное применение
> методов без потерь в обслуживании) легко достижимо уже
> сейчас или в ближайшем будущем.
Наталья, Вам приходилось внедрять прикладную криптоситему? Когда стоит требование "проверка NN подписей в секунду", а NN достаточно большое? ПРименение ЭЦП не ограничивается отправкой раз в неделю фирмой "Рога и копыта" платежки в банк на 3 рубля ;)
А помните, году в 95 был СКЗИ "Маскарад"? Ребята наизнанку вывернулись над оптимизацией (реализация симм. шифрования была быстрее, чем у тогдашней платы "Криптон"), но проверка/прстановка подписи давали задержку, ощутимую пользователем даже на единичных документах.
|
подробно о проекте
Анализ криптографических сетевых...
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
