Российские стандарты шифрования отныне официально признаны в Интернете

> В отличие от принятого ранее документа RFC 4357, носившего статус информационного, новые документы имеют статус стандарта (proposed standard)

Proposed Standard - это не стадарт. До стандарта ему как до неба, до которого он не обязательно доберется - некоторые RFC так и остались в этой фазе с каменного века.

http://www.rfc-editor.org/rfcxx00.html

>стандарты rfc именно предложенные а не навязанные :)

А что сам IETF о процедуре стандартизации думает изучить слабо?

дак это вроде не ру а уа?

>дак это вроде не ру а уа?

Ну да. Просто я не думаю что ФСБ в этом смысле принципиально отличается от СБУ.

Всё, винде точно пипец.

> Кстати, а вот интересно, будет реализация совместимая с JCE?

Опенсурсной пока не предполагается, коммерческая - в активной разработке.

Мнения по поводу API я себе еще не сформировал, поскольку JCE не я занимаюсь.

Спасибо.

>.. лучше б сдох этот долбанный ГОСТ...

А люди на нём жирующие переработаны на метан.

Эти тредование по НСД, но не включают требований по шифрованию данных. Это отдельная сертификация и в отдельной конторе.

А какого хрена они суют везде имя своей конторки:

The hash algorithm GOST R 34.11-94 has the following identifier:

id-GostR3411-94 OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) ru(643) rans(2) cryptopro(2)
gostr3411(9) }

to ivlad&shaman07 Поясните свою позицию, желательно с аргументами

>Во-первых, когда ГОСТ разрабатывали (70-е годы - холодная война), он использовался только для защиты гос-тайны - неужели вы думаете, кто-то сделал бы лазейку, позволяющую сломать шифр?!!!

В плате "Криптон", которая реализовывала ГОСТ аппаратно, была возможность получить секретный ключ через определенную последовательность команд. Это процесс любила показывать фирма "ЛанКрипто".

В плате Криптон было не только это -- там ГОСТ в режиме гаммирования был кривым -- что-то там они напутали при сложении с переносом :))

>Proposed Standard - это не стадарт. До стандарта ему как до неба, до которого он не обязательно доберется - некоторые RFC так и остались в этой фазе с каменного века.

И что? TLS значит тоже не стандарт, раз в proposed лежит?

Вот, специально скачал и прочел сие творение. Сие творение Сергей Леонтьев (горячий привет ему) начал писать еще многог лет назад. Что еще сказать -- описание формата ключей и сертификатов -- это, конечно, хорошо. Но -- про фиксированный узел замены -- ни слова. Фиксируются только константы из 34.10 и 34.11.

Опять же, уважаемые коллеги описали свои внутренние стандарты, которые они используют в Крипто-Про(МО ПНИЭИ), что полезно, но мало применительно на парактике, поскольку не получен ответ на главный вопрос -- метод определнения множества слабых ключей для данного узла замены. И вообще авторы используют не очень очевидную "гостовскую" терминологю, приводя ее чуть-ли не в транслитерации, что затрудняет чтение.

Если кто-то из сторонних производителей крпто-провайдеров поддержит этот формат ключей и сертификатов -- так я только порадуюсь.

В поддержке отечественных стандартов есть более серьезная проблема -- межплатформенная переносимость (пресловутый byte-ordering). Желающие могут создать переносимую между спарком и интелом версию ГОСТа 28147-89 в режиме гаммирования. Если есть у кого -- я с интересом на это посмотрю.

Замечательно! У идиотов еще есть поклонники...

Еще один!

Вы замечательно доказываете теорию, что в России всегда поклонялись блаженным и пьяницам!

Они Вам обязательно просветят...

Ну спороли ребята чушь...

Какие Вы у них аргументы хотите?

Справку от психиатра или кол-во выпитого спиртного?

И документ, что они среднюю школу не смогли окончить?

Вы уж конкретизируйте.

> > неужели вы думаете, кто-то сделал бы лазейку, позволяющую сломать шифр?!!!

> В плате "Криптон", которая реализовывала ГОСТ аппаратно, была возможность получить секретный ключ через определенную последовательность команд.

Таблеточку прописать? Есть термин "алгоритм" и есть термин "реализация алгоритма". Так вот: "криптон" IMHO худшая из всех реализаций... А их "драйверы" вообще отдельная песня. Руки их "программистам" поотрубать бы. Кстати не они ли перешли в "Атлас", который ЕГАИС писал? А то по "классу" ну ОЧЕНЬ похожи :-(

Извините за здоровый цинизм (среди любителей играть в бирюльки он не в фаворе), но говно всё это. Если модули СКЗИ закрыты и данных о том, как происходит их сертификация нет, о какой надежности может идти речь? Верить кому-то на слово - это верх детской наивности.

>Таблеточку прописать? Есть термин "алгоритм" и есть термин "реализация алгоритма". ...

no-dashi, для вас не будет открытием, что эту реализацию продавали за большие деньги коммерческим банкам. И дело не в программистах и секретных блоках замены - а в желании иметь доступ к секретам со стороны государства.

> а в желании иметь доступ к секретам со стороны

Хе, ты сам-то как думаешь, будет ли государство сертифицировать реализацию, к которой у неё не будет лёгкого метода взлома?

>Хе, ты сам-то как думаешь, будет ли государство сертифицировать реализацию, к которой у неё не будет лёгкого метода взлома?

Будет. Требования одни для всех. И могу сказать, что очень жесткие. И подумайте сами, а нафига что-то взламывать, если для получения информации есть гораздо более простые оперативные мероприятия? Человека ведь можно запугать, купить, обмануть, в конце-концов пальцы в дверь еще никто не отменял.

Народ! Ваше недоверие к шифрованию по ГОСТ напоминает паранойю.
Если так не доверяете, можно сделать вот что:
1. Шифруем данные алгоритмом, которому доверяем
2. Шифруем ГОСТом

И данные целы, и требования соблюдены

> Народ! Ваше недоверие к шифрованию по ГОСТ напоминает паранойю.

Вы таки не поверите, но ещё и пользуемся. И шифруем и подписываем.

>Вы таки не поверите, но ещё и пользуемся. И шифруем и подписываем.

А что мешает применить ещё один алгоритм, если ГОСТу нет доверия?

> А что мешает применить ещё один алгоритм, если ГОСТу нет доверия?

Спросите это не у меня, а у того, кто не доверяет. Лично мне накакать на его стойкость. ГОСТ -- стандарт в конторе для шифрования и подписей, так как подписываются официальные бумаги, которые в случае чего предъявляются в государственные органы. А то, что нужно спрятать подальше, я и без ГОСТа спрячу.

> no-dashi, для вас не будет открытием, что эту реализацию продавали за большие деньги коммерческим банкам

Не будет, конечно. И я даже знаю кто вынудил это делать (покупать).

> И дело не в программистах и секретных блоках замены - а в желании иметь доступ к секретам со стороны государства

Ой какие мы нежные... Секреты... Доступ... Между прочим, эти самые криптоны нужны в действительности только для общения с РКЦ Центробанка. А поскольку этот ключик шифрования хранится у _обоих_ сторон, государство замечательно получит его через ЦБ, при необходимости.

Внутри банка, между прочим, можете шифровать чем угодно и как угодно. И если уж вас так беспокоит наличие бэкдора в плате, то могу сказать страшную тайну - есть драйвер "Криптон-эмулятор" (тоже редкостное г..но), он целиком программный, и его ключи теряются при выключении питания компа.

А несуметь устроить перезагрузку при попытке НСД со стороны каких бы то ни было органов в банке, чьими секретами сочло нужным заинтересоваться государство?! Вы уж совсем какие-то сказки рассказываете.

>И что? TLS значит тоже не стандарт, раз в proposed лежит?

Да. Это не IETF Internet Standard. Соотвествующая RFC может изменяться.

> Народ! Ваше недоверие к шифрованию по ГОСТ напоминает паранойю. <...>

Дело не в ГОСТах, а в их реализации в сертифицированных СКЗИ, которыми необходимо пользоваться при взаимодействии с некоторыми гос. структурами. Под масдай, реализация этих поделий, мягко говоря, оставляет желать лучшего. В Linux\BSD же, при поддержании системы up2date эти бинари будут готично торчать занозой в мягком месте.

> В Linux\BSD же, при поддержании системы up2date эти бинари будут готично торчать занозой в мягком месте.

Эт-та вряд ли. Потому что мы, например, работаем с производителями дистрибутивов Linux, а не только с upstream-авторами OpenSSL.

Так что будут прекрасно наши модули обрабатываться up2date.

aptitude они и сейчас уже обрабатываются. Только этот репозиторий наружу пока не торчит, доступен только в локальной сети фирмы.

> Еще один! Вы замечательно доказываете теорию, что в России всегда поклонялись блаженным и пьяницам! Они Вам обязательно просветят...

Лефша, боюсь, что я Вашу теорию не доказываю нифига, посколько, я и не вхожу в целевую аудиторию проживающих в России, и не поклоняюсь никому. Ход Вашей мысли мне непонятен, но вызывает серьёзное беспокойство Ваша редкостная глупость и хамство. Попробуйте жевать вместо того, чтобы что-то говорить, может, у Вас это будет лучше получаться?

Что же касается личной неприязни к Шаману и Владу - попробуйте набраться смелости и выскажите всё, что Вы думаете о них, им в лицо, а не прячьтесь трусливо за моей спиной затевая склоки с теми, кто задаёт им вопросы. Это, как минимум, некрасиво.

> А ООО "ЛИССИ" (www.lissi.ru) уже давно встроила ГОСТ в openssl. Продукт называется LirSSL и уже заканчивает сертификацию в ФСБ.

Сам факт такого встраивания не интересен. Намного интереснее оформить доработку как открытый стандарт и протолкнуть изменения в базовый продукт.

> Поэтому нужно использовать в качестве блоков замены не абы что
> (dd if=/dev/random of=sbox.dat bs=256 count=1)

правильно !!! неужели суперкриптосовтеров не пиучили к ХМЛ ?
dd </dev/woman>/dev/xyz

А чего конкретизировать? Я спросил про аргументацию их позиции. Всего лишь.

>Но -- про фиксированный узел замены -- ни слова. Честно говоря еще не удосужил себя прочтением этих стандартов, но в rfc 4357 в разделе 11.1 рассписанны все таблицы замен, котоые использует КриптоПро.

>В поддержке отечественных стандартов есть более серьезная проблема -- >межплатформенная переносимость (пресловутый byte-ordering). Желающие >могут создать переносимую между спарком и интелом версию ГОСТа 28147-89 >в режиме гаммирования. Если есть у кого -- я с интересом на это >посмотрю.

ООО "ЛИССИ", LirSSL - поддерживаемые платформы - Intel, Sun, IBM, HP. И все работает во всех режимах.

>Ну, во-первых это будет уже в следующей версии OpenSSL.

Круто! Не думал, что комьюнити так быстро прогнется! :)

>Во-вторых, реализация TLS уже давно есть и применяется в некоторых >реальных проектах.

Это здорово!

>Кстати RFC на TLS с русскими алгоритмами пока не принят.

От нашего монополиста(не будем показывать пальцем, все и так знают о ком речь :)) всеравно не уйти! Так что стандарт - дело времени...

>В-третьих, в большинстве своем модификация приложений сводится к >добавлению одного-единственного вызова OPENSSL_config(NULL), чтобы >приложение прочитало общесистемный конфигурационный файл OpenSSL >(которого до версии 0.9.7 не было, вот его никто и не читает)

А вот этого вообще не ожидал!!!! Я думал там полный абзац будет! Если все так шоколадно - вам памятник при жизни!!! :)

> ООО "ЛИССИ", LirSSL - поддерживаемые платформы - Intel, Sun, IBM, HP. И все работает во всех режимах.

А исходники покажит? Что-то я там про download ничего не нашел :)) Или как всегда -- встроили в открытый продукт свою приблуду, после которой продукт открытым быть перестал?

> Круто! Не думал, что комьюнити так быстро прогнется! :)

Ну да. Денег взяли и прогнулись...

>Ну да. Денег взяли и прогнулись...

Не надо грязи! Это тебе не наше правительство! Здесь люди делом заняты, а не стяжательством!

>Или как всегда -- встроили в открытый продукт свою приблуду, после которой продукт открытым быть перестал?

Естественно! :) Благо лицензия позволяет... Хотя вроде подумывают об открытии кода...

Но по крайней мере точно известно, что наш ГОСТ от байт-ордеренга не сильно зависит.

>>Ну, во-первых это будет уже в следующей версии OpenSSL.

>Круто! Не думал, что комьюнити так быстро прогнется! :)

Ну два года - это не так уж быстро. Причем усилий на прогибание коммьнити было потрачено немало.

>>В-третьих, в большинстве своем модификация приложений сводится к добавлению одного-единственного вызова OPENSSL_config(NULL)

> А вот этого вообще не ожидал!!!! Я думал там полный абзац будет!

А хитрость в том, что в большинстве случаев приложения, использующие OpenSSL и знать не знают какие там алгоритмы - какой сертификат положили, с тем и будет работать. При условии что этот алгоритм вообще поддерживается. А вот создание ключей и заявок на сертификаты сильно отличаются. Но в большинстве случаев это делается самой утилитой openssl или какими скриптовыми обертками вокруг неё.

Но вот объяснение upstream-авторам приложений что эту функцию надо звать, обычно выливается во много-много страниц переписки.

>>Ну да. Денег взяли и прогнулись...

>Не надо грязи! Это тебе не наше правительство! Здесь люди делом заняты, а не стяжательством!

Поэтому деньги они берут не в качестве взятки, а в качестве платы за реализацию полезной для платящего функциональности.

Кстати, рекомендую, полезный метод - нанять одного из ключевых разработчиков OpenSource продукта для заточки оного продукта под нужды вашей конторы может оказаться гораздо дешевле, чем организовывать разработку у себя.

Да долговременный ключ не является секретным, у тебя в основе функции хэширования ГОСТ 34.11 лежит тот же ГОСТ 28147-89 в котором блоки замены одинаковы у всех, а известны для спец. орг. они должны быть в случае необходимости защиты сведений составляющие гос. тайну.

Я тут на помойке... ой, на Казакова случайно купил платку лан-крипто за 10 руб, ее можно туда прикрутить ? Или сдую с нее ценные чипы, все больше пользы. ;)

To Kentlinux:

>Но по крайней мере точно известно, что наш ГОСТ от байт-ордеренга не сильно зависит.

Я бы, все-таки, порекомендовалл бы Вам прочтитать стандарт. Не знаю, есть ли он где-то в сети, но в библиотеке стандартов вполне заказывается. В стандарте четко прописаны операции сложения по модулю 2**32 и 2**31. При этом, явно сказано, какой бит в длинном слове считаь старшим и младшим. Я лично вижу только одну проблему -- сложение с переносом при генерации гаммы в режиме гаммирования.

Режим гаммирования с обратной связью (а равно как и режим простой замены) вполне пероеносим. Правда, при переносе с интела на спрак (к примеру) результат может не сойтись с контрольными примерами. То есть, результат будет тот-же, но с точностью до порядка байт в длинном слове.

>Я бы, все-таки, порекомендовалл бы Вам прочтитать стандарт. Не знаю, есть ли он где-то в сети, но в библиотеке стандартов вполне заказывается. В стандарте четко прописаны операции сложения по модулю 2**32 и 2**31. При этом, явно сказано, какой бит в длинном слове считаь старшим и младшим. Я лично вижу только одну проблему -- сложение с переносом при генерации гаммы в режиме гаммирования.

>Режим гаммирования с обратной связью (а равно как и режим простой замены) вполне пероеносим. Правда, при переносе с интела на спрак (к примеру) результат может не сойтись с контрольными примерами. То есть, результат будет тот-же, но с точностью до порядка байт в длинном слове.

Я не юрист, и тем более не специалист по стандартам. Я просто программист.

По этому если контрольные тесты и на Intel и на SUN, и на HPUX, и на AIX отрабатывают правильно - я считаю что алгоритм перенесен на все платформы.

Очевидно, что ГОСТ 28147-89 был написан с прицелом на Intel.

Но, от того что на другой платформе порядок байт поменялся, криптостойкость не уменьшается, более того, математика остается той же самой, просто в 5-10 местах приходится "крутить числа", что является трудностями реализации, и по-сути не имеет отношения ни к какому стандарту.

А то что там в стандарте не учтена кросплатфоременность - ничего старашного - главное контрольные тесты чтобы были! :)