Алгоритмы ГОСТ в стандарте OpenPGP

А как ГОСТ относится к режимам многократного шифрования, аналогично 3DES? Как это сказывается на стойкости, какие из описанных уязвимостей способно снять, не образует ли шифрование группу?

Он и так достаточно медленный. И каких размеров тогда будет ключ 3*256? А смысл. Если ГОСТ всерьез окажется уязвим к слайд атакам или чему-то подобному, возможно тройное шифрование выведет их в разряд очень теоретических, потребовав очень много памяти для упражнений в "miss in the middle ", "meet in the middle" и т.д. но это может его и не спасти.

Образует ли он группу? Маловероятно, исходя из его структурного сходства с DES, хотя никто этот вопрос серьезно не исследовал. И уже не будет скорее всего.

Надо конечно заметить, что несмотря ни на что, ГОСТ пока еще относится к разряду стойких шифров, хотя и с несколько устаревшим дизайном. Alex Birykov и David Wagner в работе "Advanced slide attack" в 2000 году
http://now.cs.berkeley.edu/~daw/papers/advslide-ec00.ps
приводят интересные замечания насчет особенностей дизайна ГОСТа. Отмечается, что реальных успехов в его криптоанализе достигнуто мало. Им удалось применить слайд-атаку только против ослабленной версии ГОСТ (замена сложений на XOR), только против 20 раундов и при непрактично больших затратах ресурсов: 2^33 known texts, 2^70 works, 2^65 space. Если эта атака считается лучшим практическим результатом, то это хороший результат.

Атака со связанным ключем (Kelsey, Schneier and Wagner), хотя и впечатляет:

we can
carry out a related-key attack on GOST using two related keys and
probably about 2^{28} chosen plaintexts encrypted under each key.

,

но тоже абсолютно непрактична.

Так что большинство теоретических соображений и опасений насчет ГОСТа пока еще никем не подтверждены на практике.

Со своей стороны могу сказать, что поспешил называть дискуссию завершённой. Более того, Каллас обратился ко мне напрямую с вопросом, сможем ли мы (pgpru.com), если в итоге группа придёт к заключению добавлять ГОСТы в стандарт, оценить предложенные спецификации OpenPGP на предмет корректности, соответствию ГОСТам и требованиям отечественных госструктур.

Затея того стоит. Весьма часто приходится слышать вопросы со стороны представителей государственных организаций о том, поддерживает ли PGP ГОСТы и могут ли они его применять. Заинтересованные лица есть. Конечно, реализация ГОСТов — это только половина задачи. Вторая часть — сертификация программы в ФСБ. Но, так или иначе, без алгоритмической базы об этом можно даже не думать.

Каллас обратился ко мне напрямую с вопросом, сможем ли мы (pgpru.com), если в итоге группа придёт к заключению добавлять ГОСТы в стандарт, оценить предложенные спецификации OpenPGP на предмет корректности, соответствию ГОСТам и требованиям отечественных госструктур.

Посмотреть спецификации мы наверное сможем только поверхностно, мне лично тонкости требований к реализациям ГОСТа в госструктурах неизвестны.

Мне тут вспомнилось, что в Японии есть свой полузакрытый стандарт – cipherunicorn.
Нужно ли вообще включать региональные стандарты в общий формат OpenPGP
из-за заморочек с местным законодательством (Российским, японским и т.д.)?

Может, действительно делать какие-то региональные добавления к программе (plug-ins, extensions и т.д.),
но зачем это вносить в общий стандарт?

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

Кстати, если эта сертификация в итоге провалится (по чисто бюрократическим причинам), ГОСТ будут обратно убирать из стандарта или как?

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

Я тоже думаю над последним вариантом. Но не считаю включение ГОСТов в стандарт делом совсем уж нецелесообразным: на эти алгоритмы завязаны многие страны СНГ, а это весьма существенная пользовательская база.

Вот еще статья (правда от 2001 года), где описано плачевное состояние с законодательством в сфере сертификации ЭЦП: http://cybervlad.net/ecp/index.html

Выполнить противоречивые и абсурдные требования некоторых законов невозможно даже технически. Неудивительно, что они не разобрались в нашей системе сертификации. Пока законодательство не приведено в нормальный вид, выполнить требования сертификации практически невозможно.

Неужели нужно тащить весь этот российский бардак в стандарт OpenPGP?

Ни стандарту, ни приложениям это не навредит. Спецификации IETF достаточно гибки. Не каждый из определённых в RFC 2440 алгоритмов нуждается во внедрении во всякую реализацию стандарта. Существует градация: алгоритм может быть MAY — это значит, что реализация МОЖЕТ (но совершенно не обязана) его поддерживать, SHOULD — реализации СЛЕДУЕТ (рекомендуется) его поддерживать, и MUST — реализация ДОЛЖНА поддерживать алгоритм, чтобы соответствовать стандарту. В число последних входят лишь три — 3DES, SHA-1 и RSA как необходимая база для совместимости приложений OpenPGP. ГОСТы, если и попадут в стандарт, скорее всего будут классифицированы как MAY. Таким образом, каждый разработчик сможет выбирать сам глубину поддержки стандарта, но, в то же время (и в отличие от "доморощенной" реализации алгоритмов в рамках свободных идентификаторов private/experimental), приложения, поддерживающие алгоритм, сохранят совместимость между собой по данному алгоритму. Собственно, это именно то, для чего и служит стандарт.

Как "MAY" – пожалуйста, пусть делают. Но надо как-то провести грань между общеупотребительными и региональными стандартами. Нужно соблюдать принцип: хочешь иметь региональный стандарт – скачай дополнение, включи дополнительную опцию, и т.д. В общем чтобы его не было по умолчанию.

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

Это как в некоторых некоммерциализированых Linux дистрибутивах. Пользователи очень просят включить туда какой-то пакет, а разработчики им говорят – этот пакет идеологически нам не подходит. И создают для него отдельную ветку – коммерческие программы, программы с "неправильной" лицензией и т.д. Официально их в дистрибутив не включают, они существуют как-бы параллельно.


Естественно, я здесь рассуждают с точки зрения пользователя, "испорченного" идеологией "Free software". Там это оправданно. Для коммерческих программ такой принцип скорее всего неприемлем. Потребитель платит деньги и получает что хочет, а продавец расширяет рынок сбыта.

Может быть я был излишне критичен к ГОСТу и это в целом неплохой алгоритм (хотя я постарался обосновать свои сомнения в этом), но здесь принципиальный вопрос. ГОСТ не разрабатывался открытым сообществом. Это тайно разработанный алгоритм, наследие советской эпохи, он искусственно насаждается нормативными документами. Включение его в стандарт чисто коммерческий ход. Да, в нем есть потребность, но она создана искусственно. Это очень спорный вопрос.

Хмм.. Вот еще что вспомнилось. В Linux-Crypto-API тоже были желающие включить ГОСТ. Его включили в функции ядра. Но до включения в утилиты дело не дошло. А затем его обратно удалили из Crypto-API и больше туда не включали. Почему так произошло – не знаю. В рассылках нигде c информацией по этой теме не сталкивался.

Кстати, последовал ответ на мой вопрос относительно ГОСТовских алгоритмов с открытым ключом:
[quote:850197b685="cybervlad в форуме BugTraq"]шифрования с открытым ключом у нас нет как секса в СССР ;)
шифрую всегда симметрично (применительно к российским сертифицированным СКЗИ – по ГОСТ 28147-89). а вот механизм выработки сеансового ключа по сертификатам открытых ключей (вероятнее всего, по Диффи-Хеллману), видимо, каждый раз утверждается органом сертификации, ибо стандарта россйиского на этот счет нет.
]>

Более того, Каллас обратился ко мне напрямую с вопросом, сможем ли мы (pgpru.com), если в итоге группа придёт к заключению добавлять ГОСТы в стандарт, оценить предложенные спецификации OpenPGP на предмет корректности, соответствию ГОСТам и требованиям отечественных госструктур.

шифрования с открытым ключом у нас нет как секса в СССР Wink

Вот так Калласу и передайте.

Уже.

Сейчас на рассмотрение группы внесено такое предложение: прежде чем закреплять ГОСТы в OpenPGP, нужно описать черновые спецификации (переложение ГОСТов + выбранная асимметричная схема согласования секретного шифровального ключа), затем две независимые группы разработчиков реализуют их в двух приложениях и, наконец, проводятся испытания на совместимость в рамках стандарта. Если всё пройдёт успешно (и если до этого вообще дойдёт), будет приниматься окончательное решение о введении алгоритмов в RFC 2440bis. Насколько я помню, к такой практике прибегали и с некоторыми другими алгоритмами, вошедшими в стандарт. Но о том мне известно только понаслышке.

Кстати образцы S-блоков самого шифра могут быть в стандарте на хэш-функцию ГОСТа.

Да, это те, что, по словам Шнайера в "Прикладной криптографии", всплыли в реализации шифра для ЦБ РФ. Как было отмечено в одном из упомянутых Вами комментариев, они проявляют большую устойчивость к атакам на связные ключи, чем, в среднем, случайные S-блоки.

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

Локомотивом, двигающим развитие OpenPGP, всё-таки остаётся PGP Corporation. Конечно, у них к этому есть прямой финансовый интерес. Но я не считаю, что адаптация стандарта к региональным требованиям — российским, китайским, далее — везде, будет иметь негативный, разрушительный для стандарта эффект; наоборот, это будет способствовать расширению областей применения и совместимости приложений. Пока мы говорим только о самом стандарте. Архитектура реализации этих рекомендаций в приложениях — вопрос даже не второй.

Убеждён, в рамках стандарта это позитивное явление. Да, как Вы отмечали, в стандарте следует специально оговорить, что реализация тех или иных алгоритмов является региональным требованием, но в целом не обязательна. Это один из тех моментов, на которые следует обращать внимание рабочей группы при закреплении алгоритма в стандарте.

Не будет ли умышленно ослаблен алгоритм шифрования, с приходом на Рроссийский рынок, я незнаю, может там в связи с каким нибудь законом в США о экспорте, такова рода программ или нашем законодательством? А то я не вкурсе про законы =) Конешно понимаю исходный код открыт, но может это и скрывать не будут просто дя России будет спец версия =\