http://www.rfc-editor.org/rfc/rfc5830.txt
http://www.rfc-editor.org/rfc/rfc5831.txt
http://www.rfc-editor.org/rfc/rfc5832.txt
Думаю надо закончить тему искусственного интеллекта
Как будут защищаться электронные выборы или парафраз о разработанном в России гомоморфном шифровании
Пригласили меня тут помодерировать заседание экспертов
Спецоперация спецоперацией, а нормативка по расписанию.
Подходит к концу 2022-й год и, как мне кажется, уже
Что-то подзатянул я с выпуском дайджеста —
Мобилизация мобилизацией, а законодательство по ИБ
Июль всегда запоминается каким-то нескончаемым потоком
Сорри а что это значит ?
Это значит, что теперь буржуины не смогут на вопрос об усилении роли России в разных процессах, заявлять, что наши криптоалгоритмы проприетарны и никому неизвестны. Теперь мы в мировой струе… И можем требовать включения наших алгоритмов в список рассматриваемых в разных протоколах и стандартах.
Так сейчас пойдет другая волна ! "В РФ требуют какие то там лицензии !!!"
и когда в ASA будет ГОСТ? 🙂
Полный бред… ГОСТы на криптографию в виде RFC… Соединение с головой разорвано навеки…
А если серьезно, то ГОСТы рано или поздно нужно было выводить на международный уровень, но не такими методами. RFC IETF не то место, где нужно описывать стандарты шифрования.
Алексею: Все зависит от целей, которые преследовались, делая ГОСТ в виде RFC. Зная их, такое положение вещей вполне логично.
Очень интересные Contributors. Получается процесс публикации был инициирован коммерческой организацией.
Интересно… КриптоКом решил штурмовать IETF, КриптоПро ведут борьбу с RSA (чтобы наши алгоритмы попали в PKCS) — при этом известно, что реализации наших производителей почти всегда несовместимы (точнее почти всегда найдется ситуация, в которой они несовместимы).
Внимание вопрос: что же мы на выходе получим?
Главное понять, кто это "мы" 😉
Надо четко отдавать себе отчет, что западный вендор будет смотреть в сторону наших стандартов только в одном случае — он видит большой бизнес. Если этого нет, то никакие RFC и т.п. не помогут. Так что российский потребитель от такой стандартизации ничего не получит. Западному российские алгоритмы нафиг не нужны.
Лично мне хватит того, чтобы они просто осознали существование чего-то отличного от DES, AES и прочих стандартных алгоритмов — это, в идеале, сделает так, что приложения, использующие криптографию будут реально независимы от криптопровайдера. Пока это ни фига не так — достаточно почитать многочисленные ветки на форумах КриптоПро по поводу поддержки ГОСТа в Firefox и Thunderbird.
От себя могу добавить проблемы с системами управления сертификатами (например, MS FIM CM) и, банально, удостоверяющими центрами (может MS CA научиться бэкапить не RSA ключи).
А смысл в осознании? Они знают о ГОСТах. Важно чтобы признавали.
Ну а публикация RFC (на драфта — а именно RFC) — это и есть признание…
> при этом известно, что реализации наших производителей почти всегда несовместимы
В этих RFC эта проблема решена.
Несовместимость россиских криптоалгоритмов обусловлена тем, что каждый разраблотчикиспльзует собственный S-блок (который, если я не ошибаюсь, назначается 8-ым центром ФСБ). Специально смотрел: в RFC 5830 оговорено, что в RFCшных реализациях российских криптоалгоритмов все разработчики будут будут пользоваться КриптоПрошными S-блоками:
"Remark: the standard doesn't define any S-boxes. Some of them are defined in [RFC4357]"
Это переводится все-таки по-другому: "Вы должны определить узлы замен. Некотрые из них показаны в RFC таком-то". Т.е. КриптоПрошный RFC просто как пример дан. Т.е. ты и сам можешь их выбрать… если знаешь как и если тебе не нужна совместимость 😉
RFC не решает тех проблем, которые есть сейчас важнее ISO, поэтому расцениваю это как пиар акцию, но с определенным прицелом для самого Криптокома
а проблемы совместимости уже решены предыдущей серией RFC от КриптоПро……правда надо понимать, что это совместимость по принципу "встречной работы", а не одно убрал другое поставил
Для ряда людей из IETF community важно — что ГОСТ по сути первый ECC алгоритм в RFC без проблем с IPR
(intellectual property rights)
А эти RFC появились как необходимая информация при работе над
https://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-gost/
> Это переводится все-таки по-другому
Угу. В RFC 4357,кстати, сами узлы замены не определены, так что проблема выбора и совместимости остается 🙁
Собственно у DES таже проблема, если мне не изменяет память.
Правильно ли я понимаю, что в циске нет ГОСТа из-за того, что помимо его внедрения в закрытый IOS (или не закрытый) необходимо еще и проведение работ по проверке корректности его встраивания, а иначе, те требования которые заставляют использовать ГОСТ в сетях не будут удовлетворены?
С другой стороны других производителей (Checkpoint к примеру) такая штука не пугает …
Мне кажется из-за этого стопора циско теряет достаточно много, потому, что во многих крупных РФ компаниях инфраструктура выстроена на базе оборудования данной компании и из-за отсутствия интегрированного решения заказчикам приходится держать различный зоопарк …
Алексей есть ли какие либо подвижки в этом направлении у Cisco, особенно интересен SSL с ГОСТом?
2 Void Z7:
ситуация со встраиванием криптографии не совсем однозначная. Как правило, в сертификате на СКЗИ написано, что аттестацию корректности встраивания надо проводить только если речь идет о встраивании в прикладное ПО — аргумент — иначе установка СКЗИ в обычной ОС Windows было бы тоже встраивание.
Если исходить из такого предположения, то встраивание СКЗИ (например, того же Крипто Про) в шлюз безопасности Check Point — это типа не встраивание в прикладное ПО, а потому ничего аттестовывать не надо. Однако, мнения со стороны регулятора могут быть различные — некоторые разделяют такую точку зрения, некоторые нет.
Ну а у циски еще сложность в том, что КриптоПро для ISO нет 🙂
To doom:
А если себе представить все таки к примеру, что в IOS удалось внедрить криптобиблиотеку с ГОСТ кто даст гарантии, что IOS действительно вызывает функции из этой библиотеки?
Кто даст гарантии, что в самом устройстве не заложен не декларированный механизм вскрытия передаваемой информации по управляющему сигналу?
Это конечно паранойя в определенной степени, но когда во главу угла поставлена стойкость какого нибудь КВО то мысли нехорошие приходят.
Отвечаю:
1. В IOS ГОСТа нет и не будет. Проблема не в невозможности встраивания, а в том, что необходимо будет отдавать исходные коды на проверку. Ни один западный производитель нормально это пока так и не сделал. Опасений слишком много, а бизнеса слишком мало, чтобы рисковать. Как-то мы сделали такую ошибку в ожном восточном государстве. Через полгода после предоставления правительству этой страны наших исходников появилась компания с неблагозвучным названием. Второй раз на те же грабли мы не наступим.
2. Повторю — ни один из вендоров не выстроил адекватного процесса предоставления своих исходников. Все идут по пути подключения к своему софту ВНЕШНЕЙ СКЗИ. У Чекпойнта это CryptoPro, у нас это S-Terra. Только если у первых это решение никак не признаваемое регулятором, т.к. никто не проверял корректность встраивания (да и сам софт ввозился контрабандой в нарушение действующего таможенного законодательства), то у нас модуль, имеющий положительное заключение ФСБ (сертификат уже на подписи).
А вообще почти в любой стране отношение к чужой криптографии особое. Но там это отношение не распространяют на ВСЕ, а ограничиваются только госорганами, ВПК и КВО. А у нас, к сожалению, пытаются в условиях ограниченных ресурсов контролировать абсолютно все. Отсюда и проблема. Как можем отдел из двух человек, который максимум около 1000 разрешений на ввоз выдавал в год (!), выдать уже несколько десятков тысяч разрешений. За тот же период и теми же силами.
2 Void Z7:
Озвученная проблема верна и в ситуации, когда мы устанавливаем СКЗИ (криптопровайдер) на свой компьютер — где гарантия, что тот же браузер его будет использовать правильно? Просто тут надо до какого-то разумного уровня паранойи доходить — для какого-нибудь госоргана, где обрабатывается информация особой важности это очень даже резонный вопрос — а для обычной коммерческой конторы — это уже излишняя озабоченность.
2 Алексей Лукацкий:
S-terra тоже не является СКЗИ как таковой — они используют КриптоПро или СигналКом. Причем некоторые злые языки утверждают, что S-terra также совершенно незаконно используется в качестве криптошлюза, поскольку сертификата ФСБ у них нет.
Считай, что уже есть — на подписи. А что касается С-Терры в те времена, то все зависит на каком CSP они работали. Если на КриптоПро, то в ТУ на него написано, что нужно проверять корректность встраивания. А если на СигналКоме, то не нужно.
Будет переиздана культовая книга Брюса Шнайера «Прикладная криптография. Протоколы, алгоритмы, исходные тексты на языке C(Си)» — 2-е исправленное и юбилейное издание 2015 года