id: Гость   вход   регистрация
текущее время 13:49 29/03/2024
создать
просмотр
ссылки

ГОСТ-криптография и GnuPG


Недавно в libgcrypt начали добавлять поддержку российских криптоалгоритмов.
На текущий момент есть симметричный шифр (28147-89) и хэш-функции (как старая,
так и Стрибог). ЭЦП будет позже. (Кстати, а ЭЦП по 34.10-94 кому-нибудь
реально нужна? А то влом реализовывать.)


1. Принимаются критика у улучшения.
2. Есть ли у кого-нибудь желание озаботиться дизайном/реализацией для поддержки
алгоритмов в OpenPGP? GnuPG использует именно libgcrypt в качестве
криптобиблиотеки.


 
На страницу: 1, 2, 3, 4 След.
Комментарии
— SATtva (24/09/2013 20:27, исправлен 24/09/2013 20:28)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Есть ли у кого-нибудь желание озаботиться дизайном/реализацией для поддержки
алгоритмов в OpenPGP? GnuPG использует именно libgcrypt в качестве
криптобиблиотеки.

Для официальной поддержки любых новых алгоритмов в OpenPGP нужен дополнительный IETF-стандарт с описанием параметров и резервированием идентификаторов, за примером отсылаю к fileстандарту на Camellia (с асимметричными алгоритмами документ будет несколько сложнее). Всё это надо проталкивать через рабочую группу OpenPGP, так как именно этим людям реализовывать эти расширения в конечных приложениях. Пишите в список рассылки OpenPGP WG.

— lumag (24/09/2013 20:53)   профиль/связь   <#>
комментариев: 12   документов: 3   редакций: 4
Я в курсе про IETF. Группа OpenPGP была закрыта ("concluded") в 2008 году. Хотя активность в списке рассылки продолжается, последние черновики идут не от имени группы,
а от конкретных людей.

Я опасаюсь, что в одиночку мне целиком создание спеки не потянуть. Поэтому и ищу поддержку.
— Гость (25/09/2013 00:05)   <#>
Напоминает это и это. Так-то unknown уже сказал, что смысла в этом нет, были и другие посты на тему. Это нужно только для получения сертификаций и бюрократии, а для крипто самого по себе, по существу, нужен объективный стандарт, проанализированный сообществом.

Сильные шифры, которыми стоит пользоваться, IMHO, — AES и Twofish. Возможно, ещё Serpent. Короче, финалисты конкурса AES. А Camellia тоже не нужна, как и прочая экзотика.
— SATtva (25/09/2013 09:58)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Я опасаюсь, что в одиночку мне целиком создание спеки не потянуть.

Берёте RFC5581 за шаблон и обновляете своими параметрами. Как я уже сказал, спецификация — не главное. В первую очередь Вам потребуется заинтересовать участников рабочей группы: она хоть и носит неформальный характер, но без поддержки, прежде всего, разработчиков GnuPG, спецификация будет просто валяться в архиве IETF. Если же формализация Вас не интересует, можете использовать зарезервированные в RFC4880 private-идентификаторы, а сами алгоритмы добавить в GnuPG в виде подключаемых библиотек, как это делали с IDEA.
— Гость (26/09/2013 02:48)   <#>
Недавно в libgcrypt начали добавлять поддержку российских криптоалгоритмов.

С каким именно набором S-блоков?
Насколько помнится в RFC 4357 живет большая подстава. И не соответствует требованиям предъявляемым ФСБ к реализации ГОСТов.
В общем, не пожалейте времени на общение с теми, кто сертифицировал и помнит нюансы требований к реализации этих алгоритмов.
— Гость (26/09/2013 03:15)   <#>
Набор S-блоков в RFC 4357 был придуман КРИПТО-ПРО, у которой вроде бы как нет и не было ни одного продукта или библиотеки сертифицированных до гостайны. Придуман этот набор был для того, чтобы начать играть в совместимость с решениями других производителей. В секторе гражданских систем защиты информации, не содержащих сведений, составляющих государственную тайну.
Потому ряд продуктов других российских компаний имеют два режима. Один из которых сводится к поддержке этого самого RFC 4357. Для совместимости с теми решениями других компаний, которые имеют более низкий уровень сертификации.
— lumag (27/09/2013 00:36, исправлен 27/09/2013 00:37)   профиль/связь   <#>
комментариев: 12   документов: 3   редакций: 4

Пока что поддерживаются только S-блоки из примера в ГОСТ Р 34.11-94.
Как только придумаю, как именно удобно передавать настройки S-блоков
из вышележащего кода, можно будет добавить остальные блоки.
Основные направления интереса – GnuPG (S/MIME, OpenPGP), GnuTLS (PKI,
TLS под вопросом).

— Беня (27/09/2013 04:15)   <#>

Это массив из восьми uint64.
И если на С++, то
— lumag (27/09/2013 05:52)   профиль/связь   <#>
комментариев: 12   документов: 3   редакций: 4
Беня, я в курсе.
— SATtva (27/09/2013 07:51)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Я вижу только один вменяемый способ: отдельный идентификатор симметричного алгоритма под каждый набор S-блоков.
— Беня (28/09/2013 16:49)   <#>
Я вижу только один вменяемый способ: отдельный идентификатор симметричного алгоритма под каждый набор S-блоков.

Его нельзя использовать в GnuPG. Потому что наборов S-блоков для ГОСТа существует от шестнадцати и более:
  • десять утверждены Государственной службы специальной связи и защиты информации Украины
  • один утвержден в Белоруссии (СТБ П 34.101.50-2012)
  • четыре изобретены КриптоПро и отлиты в RFC4357
  • один подан российским техническим комитетом по стандартизации на ISO/IEC 18033-3 (определен в 1-м рабочем проекте Дополнения 1)
  • возможно есть еще, отличные от этих и используемые для защиты российской гостайны

При таком зоопарке имеет смысл брать лишь iso-шный вариант. Например, в своих работах Куртуа использовал набор S-блоков «хрен поймешь откуда взятый». За что и был подвергнут жесткой критики со стороны сообщества. Вполне логично, что в следующий раз он и ему подобные возьмут уже iso-шный вариант. Тем самым в GnuPG будет использован наиболее часто колупаемый вариант.

GnuPG живет в своем собственном мирке и нет вопроса совместимости с другими криптографическими продуктами российского, украинского или белорусского происхождения. Потому нет надобности зашивать все ныне известные наборы S-блоков.
— unknown (28/09/2013 21:00)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
GnuPG живет в своем собственном мирке и нет вопроса совместимости с другими криптографическими продуктами российского, украинского или белорусского происхождения.

[off]
Fix по поводу причины и следствия:
Продукты российского, украинского или белорусского происхождения живут в своём мирке, поэтому у GnuPG нет вопроса совместимости с ними.
[/off]
— Гость (28/09/2013 22:56)   <#>

Тусовка GnuPG — это толпа криптопанков. Долго и нудно ложивших с прибором как на промышленные стандарты сродни PKCS, так и на существующие де-факто. Достаточно вспомнить сколько лет GnuPG огораживалось ото всего мира убогим OpenPGP и когда начали прикручивать поддержку S/MIME и PKI.
— unknown (28/09/2013 23:15)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Одно другого не исключает. Эти промышленные стандарты тоже весьма убоги. И долго и нудно кладут и ложат на всё, что не влезает в узкое представление о корпоративной безопасности. Поэтому от них отрицаемой аутентификации и прочего скорее всего будет ещё сложнее дождаться, чем от OpenPGP. Зато в них есть проталкивание кучи местечковых бюрократических стандартов, ради которых криптографы должны уделять какое-то дополнительное внимание (а посуществу распылять силы) на анализ цирковых алгоритмов с зоопарковыми вариантами представлений констант.
— gyhsal (29/09/2013 00:15)   <#>
Кстати, а ЭЦП по 34.10-94 кому-нибудь реально нужна? А то влом реализовывать.

А кому оно может быть надо, когда есть уже ГОСТы 34.10-2012 и 34.11-2012?
На страницу: 1, 2, 3, 4 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3