LINUX.ORG.RU

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


0

0

Комитет IETF (Internet Engineering Task Force) утвердил и опубликовал новые стандарты RFC 4490, "Using the GOST 28147-89, GOST R 34.11-94, GOST R 34.10-94, and GOST R 34.10-2001 Algorithms with Cryptographic Message Syntax (CMS)", RFC 4491, "Using the GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms with the Internet X.509 Public Key Infrastructure Certificate and CRL Profile", которые описывают применение Российских криптографических стандартов и криптографических стандартов СНГ в Инфраструктуре Открытых Ключей (PKI - Public Key Infrastructure) и электронной почте.

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

>>> Источник

anonymous

Проверено: Shaman007 ()

Ответ на: комментарий от ovax

Как и со многим русским - все заховано, спрятано, недоступно. Если нужно - еб...сь сам!

sur02111976
()

Помню видел проект, который добавлял шифрование по ГОСТ в SSL
Этот http://www.lissi.ru/products/
или ещё какой-то.
Надеюсь теперь появится открытая реализация

KUser
()
Ответ на: комментарий от ivlad

А чем не понравился?
Теперь он будет стандартным алгоритмом шифрования, может появится в OpenSSL, так что всё хорошо

KUser
()

Крипто-Про с сертифицированным ГОСТовым шифрованием уже давно есть под linux,solaris,freebsd также как под оракл и цитрикс. Но это далеко не OSS.
Вот есть и OSS http://www.cryptocom.ru/OpenSource/OpenSSL_rus.html, но не сертифицированная.
Все надеюсь понимают, что российская криптография нужна только сертифицированная, а OSS НИКОГДА не сертифицируют т.к. AFAIK закрытые "блоки замены" под каждую реализацию должны быть известны соответвующим органам, зная их можно существенно понизит криптостойкость алгоритма и уменьшить кол-во переборов при brute-force

neiromancer
()
Ответ на: комментарий от neiromancer

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

neiromancer
()
Ответ на: комментарий от Shaman007

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

а причем тут линуск?

anonymous
()
Ответ на: комментарий от Shaman007

> AFAIK закрытые "блоки замены" под каждую реализацию должны быть известны соответвующим органам, зная их можно существенно понизит криптостойкость алгоритма и уменьшить кол-во переборов при brute-force

Именно это и не нравится в ГОСТе. Триста клиентов - для каждого свой блок. Замучаешься управлять всем этим хозяйством ... Тут с одними сертификатами иногда не знаешь какой у кого ... а еще и блоки !

sur02111976
()
Ответ на: комментарий от sur02111976

А нафига так много? Таблицы замен не являются закрытой информацией. Достаточно одной на всех.

Есть конечно случаи, когда для какой-то сверхтайной гос-структуры ФСБ выдает отдельную таблицу замен и заставляет ей пользоваться, но это уже прямо скажем ни банкам, ни этим организациям не надо... Так, очередная перестраховка.

Kentlinux
()

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

corpus
()
Ответ на: комментарий от neiromancer

А модуль, кажись, сертифицирован:
цитата из
http://www.cryptocom.ru/OpenSource/OpenSSL_rus.html :

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

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

KUser
()
Ответ на: комментарий от execve

> По слухам, криптопрошники активно встраивают госты в OpenSource >продукты. Так что жди исправлений для OpenSSL.

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

Kentlinux
()
Ответ на: комментарий от neiromancer

> AFAIK закрытые "блоки замены" под каждую реализацию должны быть известны соответвующим органам

Ты чего курил? таблица замен отродясь ни в какую реализацию (кроме самых кривых) не прошибавалсь и по жизни являлась "долговременной частью ключевой информации".

no-dashi ★★★★★
()
Ответ на: комментарий от KUser

>А модуль, кажись, сертифицирован: >цитата из >http://www.cryptocom.ru/OpenSource/OpenSSL_rus.html : > >Российские требования по сертификации криптографического программного >обеспечения делают законным использование решений, в которых >сертифицирован только модуль, непосредственно реализующий национальные >криптоалгоритмы.

>Поэтому наличие сертифицированного (коммерческого) криптографического >модуля, совместимого с OpenSSL, позволит пользователям применять >сертифицированные криптоалгоритмы в решениях на базе любых OpenSource >приложений, использующих OpenSSL.

Это все правильно, НО ребята из КриптоКом пошли "слишком правильным" путем - они решили перелопатить нафиг весь openssl и сделать его более алгоритмо-независимым.

Идея, не спорю, классная, и от всей души желаю им удачи, но уж больно долго все это будет. Потому что им, кроме как дописать свой патч(там до сих пор ни TLS ни SSL не пашет пока), надо уговорить народ из openssl включить в основную ветку их патч, и самое трудное, уговорить всех кто пишет свои приложения с использованием openssl переписать их, так как API поменялся сильно.

Так что им предстоит долгий, мучительный процесс...

Пожелаем им удачи.

Kentlinux
()
Ответ на: комментарий от ivlad

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

Аргументы будут? Или расстраивает, что нету аппаратных плат этого дела под сантехнику? :-)

P.S.: я сам эти "аппаратные шифраторы" люто ненавижу

no-dashi ★★★★★
()
Ответ на: комментарий от Kentlinux

Если OpenSSL включит их патч, то уговаривать никого не придётся - с течением времени народ перейдёт на новую версию
Надеюсь у них всё получится

KUser
()
Ответ на: комментарий от Kentlinux

Об этом был доклад на Протве, ищите тезизы. Коротко: ключевым стало решение нанять разработчика OpenSSL, который уже реализовал поддержку различных крипто-движков, и уже в новой версии они появятся. Ещё есть проблемы со многими приложениями, использующими специфичные для DES функции (а не более общие), но их разработчики нормально реагируют на исправляющие это дело патчи.

ajvol
()
Ответ на: комментарий от corpus

>> как-то года 3 назад пришлось реализовывать ГОСТ 28147-89 и ГОСТ 34.11-94 Р. инофрмации по нему было очень мало - полное описание стандарта на родном языке тогда предлагали купить

Есть английский перевод госта, лежит в сети уже очень давно, электронные версии на русском языке сам скачивал года 2 назад, на самом деле ничего нового по спавнению с кучей всяких описаний (включая нетленку Шнайдера) там нет.

Насчет банков и использованию в них госта. Платежные системы (Visa, Mastercard и проч.) для криптографии используют DES и 3DES, в относительно недавнем стандарте EMV (микропроцессорные карты) используется DES и RSA. Единственное для чего может использоваться гост это для документооборота между ЦБ и банком (тут я точно не знаю).

cathode
()
Ответ на: комментарий от neiromancer

>Все надеюсь понимают, что российская криптография нужна только >сертифицированная, Это правильно. Тестить реализацию кто-то должен.

>а OSS НИКОГДА не сертифицируют т.к. AFAIK закрытые "блоки замены" под >каждую реализацию должны быть известны соответвующим органам,

Правильно, AFAIK должны знать, чтобы протестить. А то ты возьмешь какую-то хрень, типа 64-х нулей, и на такой таблице замен будешь шифровать секретную инфу.

>зная их можно существенно понизит криптостойкость алгоритма и уменьшить >кол-во переборов при brute-force

Не правильно, зная что они ХРЕНОВЫЕ,можно существенно понизить криптостойкость алгоритма и уменьшить кол-во переборов при brute-force.

А то, что мы все под колпаком, что ФСБ знает таблицы замен и их нам дает такие, чтобы все легко ломалось - БРЕД!

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

Во-вторых, таблицы замен у того же КриптоПро всем известны(в этих самый RFC и расписанны подробно) и тем не менее продукты КриптоПро и остальных вендоров ставят на секретные оборонные предприятия.

Неужели вы думаете, что наше доблесное ФСБ, чтобы прочитать вашу почту, поставит под удар гос-секреты?!!!

Не обольшайтей господа! :)

Kentlinux
()

А в Kerberos можно ГОСТ встроить?

geekkoo
()
Ответ на: комментарий от Kentlinux

Kentlinux:
""""""
>а OSS НИКОГДА не сертифицируют т.к. AFAIK закрытые "блоки замены" под >каждую реализацию должны быть известны соответвующим органам,

Правильно, AFAIK должны знать, чтобы протестить. А то ты возьмешь какую-то хрень, типа 64-х нулей, и на такой таблице замен будешь шифровать секретную инфу.

>зная их можно существенно понизит криптостойкость алгоритма и уменьшить >кол-во переборов при brute-force

Не правильно, зная что они ХРЕНОВЫЕ,можно существенно понизить криптостойкость алгоритма и уменьшить кол-во переборов при brute-force.
""""""

ну и включили бы один "нехреновый" блок в ГОСТ- раз на крипкостойкость его открытость не влияет

Anonymous ★★★★★
()
Ответ на: комментарий от Anonymous

>ну и включили бы один "нехреновый" блок в ГОСТ- раз на крипкостойкость >его открытость не влияет

ГОСТ - это описание алгоритма. Зачем туда включать какие-то данные? А вот требования к свойствам таблиц замен надо включать(честно говоря не знаю есть ли в самом стандарте эти требования).

Kentlinux
()

> новые документы имеют статус стандарта (proposed standard),

proposed:

propose

гл.

1)

а) предлагать; вносить предложение

I propose a toast to the Queen. — Я предлагаю тост за здоровье королевы.

б) делать предложение о вступлении в брак, предлагать руку и сердце (кому-л. - to)

When Sam first proposed to you? — Когда Сэм первый раз сделал тебе предложение?

2) намереваться, собираться, предполагать

Man proposes, but God disposes. — Человек предполагает, а Бог располагает.

Syn:

intend, mean, be about

3) предлагать чью-л. кандидатуру, представлять (кандидата на должность)

Syn:

nominate

AS ★★★★★
()
Ответ на: комментарий от WhiteDemon

>..судя по дате оригинальной новости, еще в мае :))

Знаю :-). Но мне показалось что лучше поздно, чем никогда. Тем более мне лично эта тема близка, и я хотел послушать местных аборигенов.

anonymous
()
Ответ на: комментарий от neiromancer

> AFAIK закрытые "блоки замены" под каждую реализацию должны быть известны соответвующим органам, зная их можно существенно понизит криптостойкость алгоритма и уменьшить кол-во переборов при brute-force

Не так всё это, савсем нэ так. Во-первых, рекомендуемые блоки замены перечислены в RFC 4357.

Во-вторых, существуют "хорошие" блоки замены и "плохие", существенно понижающие криптостойкость. Поэтому нужно использовать в качестве блоков замены не абы что (dd if=/dev/random of=sbox.dat bs=256 count=1), а такие блоки, которые были протестированы на криптостойкость. Чем, в частности, и занимаются сертифицирующие органы.

vitus
()
Ответ на: комментарий от Kentlinux

>Это все правильно, НО ребята из КриптоКом пошли "слишком правильным" путем - они решили перелопатить нафиг весь openssl и сделать его более алгоритмо-независимым.

>Идея, не спорю, классная, и от всей души желаю им удачи, но уж больно долго все это будет.

Ну, во-первых это будет уже в следующей версии OpenSSL. Можете брать снапшот с сайта OpenSSL и ГОСТ-модуль для 0.9.9 с нашего сайта, и пробовать (если сумеете девелоперский снапшот собрать)

Во-вторых, реализация TLS уже давно есть и применяется в некоторых реальных проектах. Правда, пока не опубликована на сайте - надо перышки причесать, описать API, описать применение этого модуля вместе с парой десятков реальных приложений, которые мы тестировали. Кстати RFC на TLS с русскими алгоритмами пока не принят.

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

vitus
()
Ответ на: комментарий от KUser

> А модуль, кажись, сертифицирован: цитата из http://www.cryptocom.ru/OpenSource/OpenSSL_rus.html

Есть два модуля (абсолютно совместимых по набору поддерживаемых алгоритмов и слегка различающихся по набору команд конфигурации)

- Находящийся в процессе сертификации, но за деньги - Несертифицированный, но OSS.

Кстати, возможно, несертифицированный модуль будет включен в дистрибутив OpenSSL 0.9.9.

vitus
()
Ответ на: комментарий от vitus

Кстати, а вот интересно, будет реализация совместимая с JCE? Вообще, vitus, интересно было б узнать Ваше мнение как спеца, о JCE API.

svu ★★★★★
()
Ответ на: комментарий от neiromancer

>я, а OSS НИКОГДА не сертифицируют т.к.

Если верить ньюзу который тут мелькал - mylinux прошел такую сертификацию.

Вот список стандартов: http://mylinux.com.ua/mylinux-oko-nd

Третьим пунктом там идет:

НД ТЗІ 2.5-007-2001 Требования к комплексу средств защиты информации, составляющей государственную тайну, от несанкционированого доступа при ее обработке в автоматизированных системах класса «1».

r ★★★★★
()

походу янкисы асилили взлом этих алгоритмов на лету

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.