Разработан патч (http://www.cryptocom.ru/OpenSource/OpenSSL_rus.html) для OpenSSL 0.9.8a, позволяющий добавлять произвольные криптографические алгоритмы как модули engine.
В частности, реализована поддержка в OpenSSL российских криптографических алгоритмов электронной подписи GOST-1994 и GOST-2001.
URL: http://www.cryptocom.ru/OpenSource/OpenSSL_rus.html
Новость: http://www.opennet.me/opennews/art.shtml?num=6491
Это класс! Разработчикам РЕСПЕКТ!
Наши криптоалгоритмы самые устойчивые.
К сожалению, это не совсем так. Ибо в том же самом ГОСТе (в режиме шифрования) таблицы подстановки не введены в стандарт, более того, методы их генерации так же не введены в стандарт, так что, есть вероятность того, что товарищи попросту скрывают важные свойства алгоритма с целью осуществеления успешных атак на этот алгоритм. Собственно говоря, именно поэтому ГОСТ не рассматривался на конкурсе aes. Так что моё мнение таково - ГОСТ в режиме шифрования использовать не стоит.
Правда, насчёт ГОСТа в _режиме_подписи_ я не совсем уверен, может быть и имеет смысл добавить\использовать.
Если вы внимательно читали 28147-89 то таблицы замен названы долговременым ключевым элементом общим для сети ЭВМ (организации). Ключ это индивидуальный ключ абонента. И по требованиям ГОСТ таблицы замен выдают компетентные органы вместе с сертификацией устройства\программы.
Если мы будем рассматривать похоже алгоритмы заметим что в DES S-Box тоже не стандартизированы, только указаны слабые или нешифрующие варианты. Методы выработки таблиц замен можно взять из DES, но я дико сомневаюсь что тут найдется хоть один человек который сможет проверить таблицы замен на устойчивость....
Интересно почему никто не боится использовать ассиметричные алгоритмы? ведь там вполне могут подсунуть модуль составным хоть и достаточно большим - а проверить это достаточно сложно. И боюсь что сложность проверки составного числа и сложность проверки таблицы замен сравнима.
>Интересно почему никто не боится использовать ассиметричные алгоритмы? ведь там вполне могут
>подсунуть модуль составным хоть и достаточно большим - а проверить это
>достаточно сложно. И боюсь что сложность проверки составного числа и сложность
>проверки таблицы замен сравнима.
*Проверить* число на простоту-непростоту - задача тривиальная, более того, уже несколько лет существует детерминированный, а не вероятностный алгоритм проверки числа на простоту. Вот разложить число на множители - это да, весьма сложная задача.
Я уже говорил о том, что из-за отсутствия критериев проверки таблиц на "качество", доверие к таблицам, выдаваемым Кровавой Гэбнёй (tm) весьма низкое.
Насчёт методов выработки таблиц - я лично не совсем уверен, что они будут одинаково хорошо работать как для DES, так и для ГОСТ, и не совсем понимаю, при чём тут наличие тут специального человека, проверяющего таблицы на устойчивость. Мы вроде бы говорили о неполной документированности стандарта, чем грешит ГОСТ.
А если говорить об ассиметричных алгоритмах, то в "чистом виде" здравомыслящий человек их использовать не будет, как мне кажется.
Господа, для начала давайте тут почитаем про "проблемы ГОСТа" http://www.schneier.com/paper-key-schedule.html, а потом уже обсуждать НЕОБХОДИМОСТЬ выработки личной таблицы замен!!выдержка:
"We examined the security of the \standard" set of GOST S-boxes [Sch96]:
we estimate that the 12-round characteristic has probability about 2^68, which is too low to make the attack practical. Randomly chosen S-boxes were much
weaker. The average probability over 10000 random S-boxes was 2^54; other
values were in the range 2^43 to 2^80, with a large variation between trials."
Алхмимик - абсолютно с вами согласен, причем - так для информации: Примеры таблиц приведенные в ГОСТе серьезно ослабляют стойкость симметричного шифрования, в свое время это использовалось для атаки на наш центробанк, правда я не в курсе насколько удачно.
Насчёт ослабления стойкости шифрования по дефолтным таблицам - я не знал, спасибо за информацию. Вообще говоря, насколько я помню, тема ГОСТа обсуждалась в ru.crypt несколько раз на протяжении нескольких лет и, если я не ошибаюсь, к единому мнению насчёт параметров этих таблиц так и не пришли. Так что моё мнение, насчёт использования отечественной крипты отчасти на этом основывается.
>Насчёт ослабления стойкости шифрования по дефолтным таблицам - я не знал, спасибо
>за информацию. Вообще говоря, насколько я помню, тема ГОСТа обсуждалась в
>ru.crypt несколько раз на протяжении нескольких лет и, если я не
>ошибаюсь, к единому мнению насчёт параметров этих таблиц так и не
>пришли. Так что моё мнение, насчёт использования отечественной крипты отчасти на
>этом основывается.И "сертификаты" именно это удостоверяют.
Читать их надо так: "Удостоверяю, что впаренная тебе лабуда, дарагой, и взлому-то не подлежит. На нее есть ключ. Путин"
Читал, что от выбора таблицы зависит стойкость шифрования, но критерий оценки "правильности" таблицы в публичном доступе отсутствует.
Саму таблицу можно использовать как временный ключ. Сам алгоритм намного бысрее многих стандартов, если развернуть таблицу до 4K.
очередной раз поднимаю вопрос нужен ли кому либо код включения в IPSec xBSD (KAME) для поддержки ГОСТа 28147 (89-90гг) ибо оно работает, даже тесты на производительность есть. изменены части ядра КАМЕ и setkey
если надо - писаните на llelik at gmail dot com
мда таблицы подстановок это основная засада...и в общем то придуманы они скорее всего для того, чтоб все кто хотят использовать этот алгоритм ходили на поклон в органы...
Что это за ключ, если от него сильно зависит стойкость алгоритма, и которой не может быть выбран пользователем этого алгоритма...
Государственный знаете такой ключ, или скорее государство зависимый.
и этим все сказано, что тут непонятного то.