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

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

[Dmitry Eremin-Solenikov]

Привет!

вс, 10 нояб. 2019 г. в 21:31, Dmitry Belyavsky <beldmit@gmail.com>:
> On Wed, Nov 6, 2019 at 6:49 PM Alexander Bokovoy <ab@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.

Я накидал https://gitlab.com/redhat-crypto/fedora-crypto-policies/merge_requests/50,
исходя из своего понимания.
Надо доделать генераторы для openssl, gnutls и т.п. (patches are
welcome). Для gnutls постараюсь сделать во вторник.
Плюс я не включил MGM в список, но это просто решается.

С openssl будет отдельный вопрос, потому что openssl ciphers без
engine не будет нормально работать с ГОСТовыми именами.

>> Так что, вопрос к экспертам: определите, пожалуйста, что использовать для следующий понятий для старого и нового ГОСТ:
>>
>> 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 list
>> mac = HMAC-GOST+
>>
>> # This adds the GOST-EC to the beginning of the group list
>> group = +GOST-EC
>>
>> hash = +GOSTHASH
>>
>> sign = +GOST-EC-GOSTHASH
>>
>> tls_cipher = +GOST-CIPHER
>>
>> cipher = +GOST-CIPHER
>>
>> key_exchange = +GOST-EC
>>
>> Для примера, вот так выглядит подполитики выкидывания поддержки SHA1, NO-SHA1.pmod:
>>
>> # This is example subpolicy dropping the SHA1 hash and signature support
>>
>> hash = -SHA1
>>
>> sign = -RSA-PSS-SHA1 -RSA-SHA1 -ECDSA-SHA1
>>
>> Где SHA1, RSA-PSS-SHA1 и остальные имена либо стандартизированы между библиотеками, либо мапятся в стандартизированные каждым генератором отдельно.
>>
>> --
>> / Alexander Bokovoy
>> _______________________________________________
>> oss-gost-crypto mailing list
>> oss-gost-crypto@lists.altlinux.org
>> https://lists.altlinux.org/mailman/listinfo/oss-gost-crypto
>
>
>
> --
> SY, Dmitry Belyavsky
> _______________________________________________
> oss-gost-crypto mailing list
> oss-gost-crypto@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/oss-gost-crypto



-- 
With best wishes
Dmitry