<div dir="ltr"><div dir="ltr">Привет!<div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 13, 2019 at 2:28 PM Paul Wolneykien <<a href="mailto:manowar@altlinux.org">manowar@altlinux.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Всем привет. Вернувшись к работе над GnuPG я понял, что то, о чём мне<br>
несколько раз говорил Дима — что здесь нужен RFC, — действительно правда.<br></blockquote><div><br></div><div>Ура.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Согласно <a href="https://tools.ietf.org/html/rfc6637" rel="noreferrer" target="_blank">https://tools.ietf.org/html/rfc6637</a> , к каждому открытому<br>
ключу, для которого разрешено шифрование, прикладываются параметры KDF —<br>
key derivation function, т.е., в конечном счёте — рецепт: как для<br>
данного публичного ключа зашифровать симметричный ключ. Но для ГОСТ<br>
рецепт требуется свой, специфический. К тому же, есть уже несколько<br>
таких рецептов.<br>
<br>
Если следовать логике RFC 6637, то для открытого ключа ГОСТ нужно<br>
определить целых три группы параметров:<br>
<br>
* параметры ВКО (длина UKM, хэш-функция [+ её параметры]);<br>
* собственно KDF (диверсификация КриптоПро / KDF_TREE (количество<br>
итераций, сообщение-метка));<br>
* параметры шифрования (wrapping) симметричного ключа (вариант<br>
упаковки + шифр + вариант имитовставки).<br>
<br>
Если так сделать, то получится, конечно, очень и очень гибкий вариант.<br>
Но в этом как бы и заключается его отрицательная сторона: можно будет<br>
такой рецепт составить, который ослабит защиту (?) или будет противоречив.<br></blockquote><div><br></div><div>Ну, внутри у нас всё равно схема Диффи-Хеллмана с вариациями.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Другой очевидный подход — вместо кучи параметров определить в самом<br>
стандарте готовые варианты (как это сделано у Смышляева в TLS —<br>
<a href="https://tools.ietf.org/html/draft-smyshlyaev-tls12-gost-suites-05" rel="noreferrer" target="_blank">https://tools.ietf.org/html/draft-smyshlyaev-tls12-gost-suites-05</a>), и<br>
потом указывать для публичного ключа просто номер варианта. Примерно так<br>
сделано сейчас в OpenSSL, где длина UKM неявным образом определяет выбор<br>
между "старым" вариантом и вариантом "2018 года" (я прав, Дима?).<br></blockquote><div><br></div><div>Оно по факту так, но вообще этот выбор однозначно следует из выбранного шифронабора.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Ситуация, однако, осложняется ещё тем, что в OpenPGP выбор алгоритма<br>
симметричного шифрования архитектурно отделён от параметров KDF:<br>
приоритет симметричных шифров определяется глобально, на стороне<br>
_отправителя_, в то время как предпочтительные параметры KDF определяет<br>
_получатель_ сообщения (поскольку он передаёт их отправителю вместе со<br>
своим публичным ключём).<br>
И вот тут я вообще пока не представляю как быть: теоретически,<br>
наверное, ГОСТовым KEK-ом можно зашифровать произвольный симметричный<br>
ключ — хоть AES, хоть Blowfish и, конечно, хоть ГОСТ 28147 или<br>
"Кузнечик". Но с другой стороны, в том же Смышляевском TLS чётко<br>
определены случаи, какой вариант KDF с каким шифром использовать.<br></blockquote><div><br></div><div>С шифром? Не с длиной ключа?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> В итоге я пока не вижу простого и очевидного решения, которое хорошо<br>
вписалось бы в OpenPGP и не противоречило имеющимся RFC про ГОСТ.<br></blockquote><div><br></div><div>У меня вопрос ровно один. Зачем мы хотим ГОСТ в OpenPGP? </div></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature">SY, Dmitry Belyavsky</div></div>