From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: From: Paul Wolneykien Organization: ALT Linux Team To: oss-gost-crypto@lists.altlinux.org Message-ID: Date: Tue, 13 Aug 2019 14:28:30 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: ru Content-Transfer-Encoding: 8bit Subject: [oss-gost-crypto] =?utf-8?b?0JPQntCh0KIg0LIgT3BlblBHUA==?= X-BeenThere: oss-gost-crypto@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Open-source aspects of GOST Cryptography List-Id: Open-source aspects of GOST Cryptography List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2019 11:28:37 -0000 Archived-At: List-Archive: Всем привет. Вернувшись к работе над GnuPG я понял, что то, о чём мне несколько раз говорил Дима — что здесь нужен RFC, — действительно правда. Согласно https://tools.ietf.org/html/rfc6637 , к каждому открытому ключу, для которого разрешено шифрование, прикладываются параметры KDF — key derivation function, т.е., в конечном счёте — рецепт: как для данного публичного ключа зашифровать симметричный ключ. Но для ГОСТ рецепт требуется свой, специфический. К тому же, есть уже несколько таких рецептов. Если следовать логике RFC 6637, то для открытого ключа ГОСТ нужно определить целых три группы параметров: * параметры ВКО (длина UKM, хэш-функция [+ её параметры]); * собственно KDF (диверсификация КриптоПро / KDF_TREE (количество итераций, сообщение-метка)); * параметры шифрования (wrapping) симметричного ключа (вариант упаковки + шифр + вариант имитовставки). Если так сделать, то получится, конечно, очень и очень гибкий вариант. Но в этом как бы и заключается его отрицательная сторона: можно будет такой рецепт составить, который ослабит защиту (?) или будет противоречив. Другой очевидный подход — вместо кучи параметров определить в самом стандарте готовые варианты (как это сделано у Смышляева в TLS — https://tools.ietf.org/html/draft-smyshlyaev-tls12-gost-suites-05), и потом указывать для публичного ключа просто номер варианта. Примерно так сделано сейчас в OpenSSL, где длина UKM неявным образом определяет выбор между "старым" вариантом и вариантом "2018 года" (я прав, Дима?). Ситуация, однако, осложняется ещё тем, что в OpenPGP выбор алгоритма симметричного шифрования архитектурно отделён от параметров KDF: приоритет симметричных шифров определяется глобально, на стороне _отправителя_, в то время как предпочтительные параметры KDF определяет _получатель_ сообщения (поскольку он передаёт их отправителю вместе со своим публичным ключём). И вот тут я вообще пока не представляю как быть: теоретически, наверное, ГОСТовым KEK-ом можно зашифровать произвольный симметричный ключ — хоть AES, хоть Blowfish и, конечно, хоть ГОСТ 28147 или "Кузнечик". Но с другой стороны, в том же Смышляевском TLS чётко определены случаи, какой вариант KDF с каким шифром использовать. В итоге я пока не вижу простого и очевидного решения, которое хорошо вписалось бы в OpenPGP и не противоречило имеющимся RFC про ГОСТ.