[oss-gost-crypto] Интеграция ГОСТ в crypto-policies

[Dmitry Belyavsky]

Привет!

On Wed, Nov 6, 2019 at 6:49 PM Alexander Bokovoy <ab at altlinux.org> wrote:

> Привет!
>
> В последних версиях crypto-policies (
> https://gitlab.com/redhat-crypto/fedora-crypto-policies/), которые уже
> присутствуют в Fedora 31, появилась поддержка "вторичных политик".
>
> "Вторичные политики" позволяют добавить разрешения на использование
> специфичных крипто-систем поверх имеющейся системной политики. Даже есть
> заготовка для ГОСТ, но она не работает, потому что не описывает конкретные
> шифронаборы, которые можно разрешать.
>
> Вот дополнительный модуль политики для ГОСТ:
> https://gitlab.com/redhat-crypto/fedora-crypto-policies/blob/master/policies/modules/GOST.pmod.
> Этот модуль определяет внутренние имена для генераторов политик конкретных
> библиотек. Например, openssl генератор:
> https://gitlab.com/redhat-crypto/fedora-crypto-policies/blob/master/python/policygenerators/openssl.py.
> Этот генератор (как и другие) не содержит преобразований из внутренних имен
> ГОСТ, определенных в GOST.pmod в имена, понимаемые библиотеками.
>
> Фактически, это заготовка, которую нужно доработать.
>
> Преобразование нужно как-то определить -- оно позволяет нам описать
> предпочитаемые шифронаборы и управлять их выбором. Если таких наборов будет
> несколько (старый ГОСТ, современный ГОСТ и так далее), то мы можем описать
> их в разных дополнительных модулях (GOST-OLD, GOST, etc), но нам нужно
> договориться о том, во что используемые в них имена будут преобразованы для
> каждой библиотеки, поддерживающей ГОСТ.
>

С единством имён у нас плохо. Для openssl в своё время часть имён придумали
мы в Криптокоме, и не всегда удачно.
Есть старые ГОСТы, которые потихоньку вымирают, и есть новые, частично
дублированные в RFC.


> Так что, вопрос к экспертам: определите, пожалуйста, что использовать для
> следующий понятий для старого и нового ГОСТ:
>
> 1) HMAC
>

HMAC по ГОСТ он и есть HMAC. То есть если там базовый примитив ГОСТовый, то
сам он ГОСТовый. Другой вопрос, что в ГОСТах есть ещё минимум 3 варианта
MAC: на старом ГОСТ, и OMAC на новом. Но для OMAC тоже смотрим на базовые
примитивы.


> 2) group
>

Тут я предлагаю брать то, что описано в
https://tools.ietf.org/html/draft-smyshlyaev-tls12-gost-suites-06#section-9


> 3) hash
>

Три штуки. ГОСТ Р 34.11-94, ГОСТ Р 34.11-2012 в двух вариантах. RFC 6986.


> 4) signature
>

ГОСТ Р 34.10-2001 и ГОСТ Р 34.10-2012. RFC 7091.


> 5) TLS cipher
>

Я бы брал https://tools.ietf.org/html/draft-smyshlyaev-tls12-gost-suites-06


> 6) key exchange
>

Вот как его выделить, я не знаю. Идеологически это (EC)DH, по факту с
вариациями.

>
> Вот так это выглядит в подполитике GOST сейчас:
>
> # This adds the HMAC-GOST at the end of the mac listmac = HMAC-GOST+# This adds the GOST-EC to the beginning of the group listgroup = +GOST-EChash = +GOSTHASHsign = +GOST-EC-GOSTHASHtls_cipher = +GOST-CIPHERcipher = +GOST-CIPHERkey_exchange = +GOST-EC
>
> Для примера, вот так выглядит подполитики выкидывания поддержки SHA1,
> NO-SHA1.pmod:
>
> # This is example subpolicy dropping the SHA1 hash and signature supporthash = -SHA1sign = -RSA-PSS-SHA1 -RSA-SHA1 -ECDSA-SHA1
>
> Где SHA1, RSA-PSS-SHA1 и остальные имена либо стандартизированы между
> библиотеками, либо мапятся в стандартизированные каждым генератором
> отдельно.
>
> --
> / Alexander Bokovoy
> _______________________________________________
> oss-gost-crypto mailing list
> oss-gost-crypto at lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/oss-gost-crypto
>


-- 
SY, Dmitry Belyavsky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.altlinux.org/pipermail/oss-gost-crypto/attachments/20191110/7e64011a/attachment.html>