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

GOST 28147 – 89, "Systems of the information treatment. Cryptographic security. Algorit
hms of the cryptographic transformation", (1989).

GOST 34.10 – 94, "Information Technology Cryptographic Data Security Produce and

Check procedures of Electronic Digital Signature based on Asymmetric Cryptographic Algorith
m", (1994).

GOST 34.11 – 94, "Information Technology Cryptographic Data Security Hashing Function"
, (1994).

так назывались описания ГОСТов. Нашел в списке литературы. Как называется новый ГОСТ для подписи (с эллиптическими кривыми) – не знаю.

А вот здесь описание за деньги я так понял (и названия новых ГОСТов).

GOST R 34.10-2001
ГОСТ Р 34.10-2001 – вот так он называется (самый новый)

Классическая работа: [Inf] J. Pieprzyk, L. Tombak,
"Soviet Encryption Algorithm,"
Preprint 94-10, Department of Computer Science, The University of Wollongong, 1994.
ftp://ftp.cs.uow.edu.au/pub/papers/1994/tr-94-10.ps.Z

(ссылка не работает :-(

Markku-Juhani Saarinen,
C implementation and test vectors for GOST hash function,
http://www.tcs.hut.fi/~mjos/gosthash.tar.gz
[The implementation is of GOST-Hash, but this archive also contains a draft translation into English of the GOST 28147-89 standard.]

Вот еще много чего:
http://vipul.net/gost/

http://vipul.net/gost/ — наиболее информативна. Спасибо. Всё, что было нужно, нашёл.

http://vipul.net/gost/ — наиболее информативна. Спасибо. Всё, что было нужно, нашёл.

Там только блочный шифр и хэш. А подпись они включать собираются? Особенно новую?

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

К слову... В качестве алгоритма с открытым ключом у нас только RSA для госструктур разрешён?

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

В банковской сфере RSA находит весьма широкое применение (и для ЭЦП в том числе), но для банковских структур требования менее жёсткие. Они там и 3DES'ом пользуются.

Вот ещё вопрос. Какова сравнительная стойкость DES и ГОСТ? Разумеется, если выносить за скобки длину ключа и полный перебор. Я имею в виду конкретно устойчивость к известным криптоаналитическим атакам.

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

Если сравнивать 3DES и ГОСТ, то DES изначально спректирован намного лучше.
(IMHO).

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

Размер S-блоков мал, критерии их создания не опубликованы, сами значения S-блоков не определены в стандарте.

Единственно, что можно сказать хорошего – добавление ключа сложением по модулю должно увеличивать (хотя и не значительно) стойкость к дифференциальному CA.

Ключевое расписание крайне примитивно (можно сказать оно вообще отсутствует) – в качестве раундовых подключей используются одни и теже подблоки основного ключа без какой-либо обработки. Похоже, создатели алгоритма не думали об "Related key attacks" и т.д. Также любая атака, восстанавливающая подключи раунда восстановит и основной ключ.

В ГОСТЕ были открыты слабые ключи, короткие циклы. Его нельзя использовать в качестве PRNG-генервтора в режиме OFB.

Отечественная научная печать по-прежнему превозносит стойкость ГОСТа, зарубежная просто утратила к нему интерес. В начале девяностых просто не было шифра с большой длиной ключа, а ГОСТ уже был к тому времени давно известен и свободен для использования. Когда за рубежом было создано большое число новых алгоритмов, интерес к ГОСТу был утрачен. Новых публикаций по нему нет. Скорее всего он малостоек к новым видам криптоанализа, при этом проигрывая в стойкости DES/3DES, если даже привести размер ключа и число раундов к общему знаменателю.

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

Еще раз повторю, российские публикации пишут совершенно обратные вещи, а российские специалисты реагируют на критику ГОСТа неадекватно болезненно. Думаю тут дело в предвзятости.

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

Патриотизмом сыт не будешь, на вещи надо реально смотреть. :)
Спасибо. Весьма информативно.

Насчет S-блоков: хорошая работа "A Family of Trapdoor Ciphers" Vincent Rijmen, Bart Preenel.

Они доказали, еще в середине девяностых, что создатель S-блоков можно вставить в них возможность легкой дешифровки и остаться при этом необнаруженным (нельзя выявить известными методами анализа скрытую "троянскую сущность" S-блоков. Были сконструированы tLOKI и tCAST – троянские версии шифров, основанные на этих способах генерации S-блоков.

Теперь требуется полная публикация процесса создания S-блоков и доказательства ее незлонамеренности. (Это было требование конкурса AES). Например, для генерации использовалась известная фраза и функция SHA, а затем опубликован алгоритм отбора значений из этого потока для заполнения S-блоков.

Public Key Encryption Besides the obvious use by government agencies to catch dangerous terrorists and drug dealers, trapdoor block ciphers can also be used for public key cryptography. For this application on selects a block cipher with variable S-boxes and makes it widely available (it is a system-wide public parameter). Bob generates a set of S-boxes with a secret trapdoor. These S-boxes form his public key. If Alice wants to send a confidential message to Bob, she gene
rates a random session...

We conclude that the danger of trapdoors in block ciphers is real.

© Vincent Rijmen, Bart Preenel.

Вот и пользуйся после этого неизвестно откуда взятыми S-блоками.

Похоже, рабочая группа пришла к заключению (и информация unknownа оказалась очень полезной в обсуждении), что стоит сохранить статус-кво. Не далее, как два месяца назад из стандарта была исключена схема подписания по Эльгамалю (из-за сложностей в реализации), и добавление в стандарт технически устаревшего алгоритма будет непоследовательным шагом, всё равно, как если бы туда был включён DES.

Это не значит, что ГОСТ не может появиться в реализациях OpenPGP. Просто разработчикам придётся полагаться на собственные навыки, и использовать для алгоритмов идентификаторы private/experimental. Разумеется, о совместимости с другими реализациями в этом случае говорить не придётся.

Дискуссия ещё не завершена, но всё к тому идёт. И Хал Финни (OpenPGP), и Дэвид Шау (GnuPG) уже высказались в подобном плане. Подождём, что скажет Каллас.

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

Ссылки:
http://www.mirrors.wiretapped......phy/algorithms/gost/
Обратите внимание на комментарии.

http://www.schneier.com/paper-key-schedule.pdf
(про ГОСТ там тоже есть)

В догонку: из-за слишком простой функции раунда ГОСТ должен плохо противостоять новым видам атак типа Slide, которые являются более сильными, чем Related Key и потенциально не зависят от числа раундов.
Против всех шифров есть варианты атак, но ГОСТ выглядит серьезно уязвимым.
Вообще по современным понятиям у него явно недостаточный дизайн.
32 раунда тоже не достижение. Вспомним, взлом 31 раунда Skipjack это наглядно показал.

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

Мое мнение, по дизайну DES сильнее. Неплохое для своего времени ключевое расписание, которое за счет сдигов исключало почти все слабые ключи (этот прием используется до сих пор), хорошие диффузионные свойства линейных компонентов, продуманность S-блоков.

и добавление в стандарт технически устаревшего алгоритма будет непоследовательным шагом, всё равно, как если бы туда был включён DES.

Согласен. Нужно еще что-то решать с хэш-функциями. Потихоньку искать замену SHA.