Комментарии 12
в режиме MGM (я бы сказал, улучшенной версией GCM)
Ага, эта версия настолько "улучшена" что требует двойного применения блочного шифра (в случае Кузнейчика ещё и не блещущего производительностью) вместо одинарного в GCM (строго говоря, 2*n+m+4 против n+m+1, где n и m — кол-во блоков в шифруемом сообщении и в аутентифицируемых данных соответственно). Не говоря уже о "гениальном" решении использовать длину nonce равную 127-битам (63 бита для Магмы).
* Не ясно что не так с производительность Кузнечика (реализаций его куча, варианты оптимизаций (предрасчёт таблиц) тоже есть)
* Посмотрите для чего применяется nonce и увидите что верхний бит используется для указания режима (шифрование/аутентификация). Я думаю в любую реализацию MGM передаётся 128-бит nonce, просто верхний бит обнуляется и MGM явно показывает потерю энтропии в этот 1-бит
Не ясен ваш сарказм на пустом месте.
MGM в каком-то месте в плане безопасности хуже?
Где я такое утверждал? Вопрос в том, что соразмерно ли подобное падение производительности заявленным улучшениям в безопасности. Если уж и платить за двойное шифрование, я лучше выберу, при наличии возможности, вариант SIV режима, который даст misuse resistance, свойство гораздо более ценное на практике, чем, насколько я понимаю, в большей степени теоретическое усовершенствование заявленное в статье MGM.
Не ясно что не так с производительность Кузнечика (реализаций его куча, варианты оптимизаций (предрасчёт таблиц) тоже есть)
По сравнению с хардварно ускоренным AES (да, сравнение не честное, но оно нынче практически в каждом утюге) и с ARX шифрами всё достаточно грустно. Не говоря уже о том, что использование таблиц, да ещё и таких крупных как в подходе с предрасчётом, сразу ставит нас под прицел тайминг атак (а bit sliced реализаций ГОСТовых шифров я в открытой литературе найти не смог). Плюс bit sliced реализация AES адаптированная под SIMD инструкции, так же значительно превосходит по производительности Кузнейчик, даже использующий предрасчитанные таблицы.
Я думаю в любую реализацию MGM передаётся 128-бит nonce, просто верхний бит обнуляется и MGM явно показывает потерю энтропии в этот 1-бит
С таким подходом вы можете получить по сути nonce reuse, т.к. внешне передавая разные nonce вы будете использовать одно и то же значения счётчика сначала для шифрования, а потом для аутентификации. Причём эту ошибку вполне вероятно допустить на практике, например, используя для nonce счётчик с Little Endian порядком байт. Не утверждаю, что подобная ошибка может привести к взлому режима на практике, но хорошего в этом в любом случае мало. Хорошая реализация, на мой взгляд, должна выдавать ошибку если 128-й бит не равен нулю.
Найдите мне ещё один AEAD режим который бы использовал nonce с длиной не кратной восьми битам. Даже авторы MGM когда я обратил внимание на эту особенность в переписке с ними, привели примеры аналогичных подходов, но которые, сюрприз, использовали nonce таки кратное 8 битам.
* Всё зависит от реализаций. Я видел и более быстрые аппаратно ускоренные Кузнечики, чем AES-ы. Про timing атаки не поспорю — но это касается и AES-а того же в той же степени.
* Поэтому чтобы не получиться nonce reuse и говорят про 127/63 векторы инициализации. Мои реализации MGM явно проверяют верхний бит и не дают такое использовать. Nonce reuse фатален.
Это всё не nonse-reuse-resistant алгоритмы, использующие таблицы замены — да, это всё мне тоже не нравится. Но я изначально только сказал что MGM является улучшенной версией. Да, не уточнил по какому параметру. С безопасностью у него лучше. И мне очень нравится что у нас безопасность ставят выше остального. Удручает двойное применение шифрования? Поставьте в два раза больше шифраторов/процессоров — не такое уж оно всё и медленное в софте (а в железе не проблема).
Оптимизированная реализация кузнечика в MGM-режиме практически не уступает по скорости чистому шифрованию. Но это надо щепотку магии в правильной реализации конкретного режима работы реализовать на ассемблере.
У процессоров x86 обычно достаточно портов в бэкенде, чтобы распараллелилить и конвейеризировать вычисления.
Для ARM может быть замедление(но такая оптимизация исторически не является моей компетенцией), хотя структура новых ядер X1 выглядит очень похожей на x86 в области бэкенда.
Распараллеливание (в т.ч. instruction-level parallelism) в данном случае ни на что не влияет. И GCM, и MGM оба поддерживают параллельную обработку блоков, поэтому MGM неизбежно будет как минимум в два раза медленнее GCM. Иначе говоря, с GCM вы условно будете шифровать за раз два блока, а с MGM вы будете за раз шифровать один блок и аутентифицировать его.
Я видел и более быстрые аппаратно ускоренные Кузнечики, чем AES-ы.
Вопрос в распространённости на пользовательском железе (мы же о потребительском TLS говорим, а не о спец. применениях). С практической точки зрения Кузнейчик это достаточно медленный алгоритм и сверх этого уполовинивать его производительность ради теоретических улучшений безопасности, на мой взгляд, нецелесообразно.
но это касается и AES-а того же в той же степени
Нет, не касается, т.к. для него есть хорошо известные bit sliced реализации. Уже много лет никто, хоть немного разбирающийся в теме, не реализует AES для применения в продакшене через таблицы подстановок. Для Кузнейчика тоже можно реализовать bit sliced реализацию, но, насколько мне известно, никто этого не делал.
говорят про 127/63 векторы инициализации
Другие алгоритмы вполне обходятся nonce кратным 8 битам, и только MGM уникален.
И мне очень нравится что у нас безопасность ставят выше остального.
Везде есть баланс. Вы же не поддержите увеличение количества раундов блочного шифра в 2-3 раза для улучшения "безопасности"? Накручивать теоретическую безопасность в ущерб производительности очень плохо влияет на возможности распространения алгоритма и размер области возможных применений (например, я бы не стал применять Кузнейчик, и тем более режим вроде MGM, для шифрования дисков и данных в оперативной памяти).
И насчёт, "выше всего остального". Давайте просто вспомним про то, что разработчики уже который год не могут внятно объяснить происхождения S-боксов и про теоретический взлом Стрибога урезающий безопасность 512-битного варианта почти в два раза.
не такое уж оно всё и медленное в софте
Для пользователя ещё куда не шло, но вот на сервере MGM с Кузнейчиком без аппаратного шифрования, будет кушать ресурсов весьма заметно по сравнению с аналогами (иначе говоря, сервис с поддержкой ГОСТового TLS будет стоить дороже, тем самым отрицательно влияя на его конкурентоспособность).
В TLS 1.3 есть спорные и очень опасные, с точки зрения безопасности, режимы работы когда application данные посылаются сразу же уже вместе с первым ClientHello ещё совершенно не аутентифицированной стороне (EarlyData)
Прошу прощения вроде бы TLS 1.3 0-RTT (EarlyData) работает только с повторным согласованием ?
Каждый сам решает за/против
Согласен с Вами. Считаю что для "обычных" инфо-сайтов без регистрации и корзины покупателя вполне допустимо.
С одной стороны Wireshark показывает при повторном соединении на 3 (ТРИ) транзакции меньше если используется TLS 1.3 0-RTT плюс TCP Fast Open.
С другой стороны мало того что это всё нужно включать на сервере, так ещё и в браузерах ни в одном по-умолчанию не включено да и не во всех браузерах вообще включить можно :)
Публикации
Потроха IPsec, меримся с TLS 1.3, ГОСТ и Go