#3des — Public Fediverse posts

Как и в любой сфере вокруг криптографии полно новостей из ничего. Претендующих не столько на сенсации, сколько выпускаемых в мир лишь для создания в дальнейшем псевдо-правдоподобного маркетинга. Как смешать всё в кучу и якобы обосновано объявить использование ряда алгоритмов небезопасными?

TL;DR: пост о том, чем именно определяется реально используемая на практике криптография. А крики и суета ориентированы на аудиторию понятия не имеющей о стандартах и регламентирующих документах.

Имеет ли смысл при всём этом раскладе ставить использование «Магма» в один ряд с использованием таких же «устаревших» #Triple-DES / #3DES и #Blowfish? Только потому, что они все используют при шифровании блоки длиной 64-бит, но при этом имеют более чем разумную длину ключа? Обосновывая это устаревание киванием в сторону #SWEET32 атаки?

Это определяется режимом использования любого из этих шифров:

• какой режим шифрования выбран
• какой «padding mode»
• использование «key meshing» / KDF при этом.

Громогласно и с каждого утюга рассказывалось о чём-то вроде #SWEET32 атаки. Если что-то и пояснялось, то весьма путано и заумно, не для обывателей. Суть при этом сводилась и сводится к тому что:

1. Для получения возможности угадать содержимое HTTP-cookies надо мониторить долго существующее HTTPS-соединение между браузером и сайтом, сохранив 785 гигабайт трафика.
2. Надо создавать внутри этого соединения большое число запросов для заранее предсказуемых данных в ответах, а токен аутентификации должен передаваться в каждом http-запросе.
3. Подчёркивать, успешное подтверждение, мол исследователям удалось сделать это меньше чем за пару дней с помощью специального JavaScript-кода для генерации трафика.

А ничего, что никакие вменяемые библиотеки шифруют массивы данных постоянно меняя сессионный ключ?
В крайнем случае #TLS библиотеки ограничивают продолжительность сессий TLS-соединений вообще в целом, а не только для 64-битных шифров, заново устанавливая соединение.
А тот же #OpenVPN давно содержит принудительный повторный выпуск ключей (reneg-bytes 64000000).

Использование ротации ключей для ГОСТ 28147-89 / «Магма» регламентируются официальными документами (использование KDF определяется рекомендациями 1323565.1.022-2018 и 50.1.113-2016) без соответствия этим требованиям в РФ не получить сертификат о корректно реализованной криптографии.

Да и более скоростной вариант такой ротации — key meshing — изменении ключа каждые 1024 байта восходит аж к 2006 году и описан в RFC 4357.
Который именно про ГОСТ 28147-89 и в целом определяет:

• режимы шифрования,
• алгоритм усложнения ключей (key meshing),
• режим заполнения (padding mode),
• S-box таблицы перестановок (S-преобразования);

Однако, про RFC 4357 чаще всего вспоминают в несколько ином контексте (см. в конце). И такие вещи как padding mode и key meshing из этого RFC на всём фоне суеты с узлами замены (S-Box) конечно же теряются. Однако, описанный key meshing является гораздо более производительным вариантом классической ротации ключей посредством KDF. Однако в инициативе #КриптоПро имеется одно упущение — не упомянуто каким именно образом изменяется вектор инициализации (IV) во время этого key meshing.

В тоже время, при использовании в TLS 1.2 российского алгоритма «Магма» необходимо реализовывать способ работы с ключами согласно рекомендациях по стандартизации 1323565.1.020-2018).
И сам по себе подход используемого key meshing выполняется исходя из режима шифрования. Для примера можно ознакомиться с режимами #CTR-ACPKM и #OMAC-ACPKM.
Т.е. ACPKM — это Advance Cryptographic Prolongation of Key Material
а CTR-ACPKM делает возможным работа блочного шифра в поточном режиме (вместо потокового).
и OMAC-ACPKM относится к обычным #MAC (выработка имитовставки) — средствам проверки и обеспечения целостности данных.
Эти режимы в России описаны в рекомендациях по стандартизации 1323565.1.017-2018.

И вот у кого после этого всего сохранится впечатление дремучей отсталости РФ в вопросах собственной криптографии на фоне работ прогрессивного мирового сообщества по выведению из эксплуатации устаревших блочных алгоритмов в 64-битными блоками?
«Кузнечик» появился в ГОСТ 34.12-2015 отнюдь не потому, что ГОСТ 28147-89 якобы устарел, потому что нужно вводить развиваться, вводя в обиход и оборот нечто более современное. Поскольку само собой на ровном месте не появится нечто способное когда-нибудь в дальнейшем заменить ГОСТ 28147-89 в лице «Магма».

—————————

Про суету вокруг RFC 4357 — именно в нём были обозначены параметры таблицы перестановок, предложенные #CryptoPro:

• OID: 1.2.643.2.2.31.4 (id-Gost28147-89-CryptoPro-D-ParamSet)
• OID: 1.2.643.2.2.31.3 (id-Gost28147-89-CryptoPro-C-ParamSet)
• OID: 1.2.643.2.2.31.2 (id-Gost28147-89-CryptoPro-B-ParamSet)
• OID: 1.2.643.2.2.31.1 (id-Gost28147-89-CryptoPro-A-ParamSet)

Это восходит к тому, что сам по себе ГОСТ 28147-89 позволяет использование различных наборов S-Box'ов, описывая тем самым не один алгоритм, а целое семейство.

И только через десять лет после RFC 4357, уже в ГОСТ 34.12-2015, на государственном уровне оказался официально зафиксирован набор S-Box'ов для однозначного определения шифра «Магма» — один конкретный вариант из множества реализаций ГОСТ 28147-89.
Соответственно, так же создал и RFC 7836 хорошо известным ТК 26 Росстандарта (Техническим комитетом по стандартизации «Криптографическая защита информации»). Описываемый набор S-Box'ов получил обозначение OID: 1.2.643.7.1.2.5.1.1, id-tc26-gost-28147-param-Z.

#маркетинг #криптография #шифры #crypto #cryptography #KDF #инфобез #infosec @Russia