Как и в любой сфере вокруг криптографии полно новостей из ничего. Претендующих не столько на сенсации, сколько выпускаемых в мир лишь для создания в дальнейшем псевдо-правдоподобного маркетинга. Как смешать всё в кучу и якобы обосновано объявить использование ряда алгоритмов небезопасными?
TL;DR: чем именно определяется реально используемая на практике криптография. А крики и суета ориентированы на аудиторию понятия не имеющей о стандартах и регламентирующих документах.
Имеет ли смысл при всём этом раскладе ставить использование «Магма» в один ряд с использованием таких же «устаревших» #
Triple-DES / #
3DES и #
Blowfish? Только потому, что они все используют при шифровании блоки длиной 64-бит, но при этом имеют более чем разумную длину ключа? Обосновывая это устаревание киванием в сторону #
SWEET32 атаки?
Это определяется режимом использования любого из этих шифров:
- какой режим шифрования используется
- какой «padding mode» (дополнение до размера блока)
- ротацией ключей («key meshing» или KDF).
Реалистичность атак на алгоритмыГромогласно и с каждого утюга рассказывалось о чём-то вроде #
SWEET32 атаки. Если что-то и пояснялось, то весьма путано и заумно, не для обывателей. Суть при этом сводилась и сводится к тому что:
Для получения возможности угадать содержимое HTTP-cookies надо мониторить долго существующее HTTPS-соединение между браузером и сайтом, сохранив 785 гигабайт трафика. Надо создавать внутри этого соединения большое число запросов для заранее предсказуемых данных в ответах, а токен аутентификации должен передаваться в каждом http-запросе. Подчёркивать, успешное подтверждение, мол исследователям удалось сделать это меньше чем за пару дней с помощью специального JavaScript-кода для генерации трафика.А ничего, что нормальные библиотеки шифруют массивы данных постоянно меняя сессионный ключ?
В крайнем случае для #
TLS библиотеки ограничивают продолжительность сессий TLS-соединений вообще в целом, заново устанавливая соединение, не только для алгоритмов с 64-битным блоком.
И тот же #
OpenVPN давно содержит принудительный повторный выпуск ключей (reneg-bytes 64000000).
Ротация ключей и key meshingИспользование ротации ключей для ГОСТ 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» конечно же теряются на фоне суеты с узлами замены (S-Box).
Однако, описанный «key meshing» является гораздо более производительным вариантом классической ротации ключей посредством KDF. В данной инициативе #
КриптоПро не описанным является лишь то, каким именно образом изменяется вектор инициализации (IV) в контексте «key meshing».
ГОСТовая криптография в TLS 1.2При использовании российского алгоритма «Магма» в TLS v1.2 ротация ключей реализовывается согласно рекомендациям по стандартизации
1323565.1.020-2018.
А сам по себе подход к варианту используемого «key meshing» определяется исходя из того самого «режима шифрования». Для примера можно ознакомиться с режимами #
CTR-ACPKM и #
OMAC-ACPKM — Advance Cryptographic Prolongation of Key Material.
где #
CTR-ACPKM делает возможным работу блочного шифра в поточном режиме (как потоковый шифр),
а #
OMAC-ACPKM относится к обычным кодам #
MAC — средствам проверки и обеспечения целостности данных (выработка имитовставки в русскоязычной терминологии).
И это более продвинутый вариант, позволяющий уйти от проблем с тем подходом, который #
КриптоПро предложили в RFC 4357. А именно, решает беду сокращения множества доступных ключей по мере продвижения во времени.
Описывается, опять же в очередных рекомендациях по стандартизации
1323565.1.017-2018.
Отсталость устаревшей «Магмы»У кого после всего упомянутого сохранится впечатление дремучей отсталости РФ в вопросах собственной криптографии? На фоне работ прогрессивного мирового сообщества по выведению из эксплуатации устаревших блочных алгоритмов в 64-битными блоками :)
Т.е. тот же «Кузнечик» появился в ГОСТ 34.12-2015 отнюдь не потому, что ГОСТ 28147-89 якобы устарел, потому что нужно вводить развиваться, вводя в обиход и оборот нечто более современное. Поскольку само собой на ровном месте не появится нечто способное когда-нибудь в дальнейшем заменить ГОСТ 28147-89 в лице «Магма». Есть и 2018 года ГОСТ 34.12-2018, который так же продолжает описывать «Магма» как один из основных рабочих шифров.
—————————
Про суету вокруг 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 #
GOST28147-89 #
lang_ru @
Russia @
RUssian Reposter
Alexey Skobkin
Habr
🅴🆁🆄🅰 🇷🇺
betamax65
TheReviewCenter
betamax65
Iron Bug
ITSEC News
dispatch