Рейтинг:6

TLS 1.3. Почему не указаны режимы шифрования, а затем MAC?

флаг cn

Я некоторое время ломал голову, почему TLS 1.3 не включает никаких режимов шифрования, а затем MAC (EtM). Все предыдущие проблемы с TLS были вызваны MAC-адресами и шифрованием. Принимая во внимание, что шифрование, а затем MAC позволяет избежать всех проблем, вызванных заполнением в прошлом, поскольку получатель может проверить целостность сообщения без необходимости сначала расшифровывать сообщение, а затем правильно обрабатывать искаженное дополнение.

Что меня раздражает, так это то, что существует довольно много микроконтроллеров со встроенным аппаратным ускорением AES. Однако что-то вроде умножения без переноса для GCM действительно существует только на серверных и настольных процессорах.

Хотя вместо этого используется ChaCha20-Poly1305, это означает, что вы отказываетесь от использования оборудования AES на микроконтроллерах. Хотя ChaCha20 хорошо работает с 32-битными микропроцессорами, он по-прежнему будет потреблять больше энергии, чем встроенное оборудование AES, и, вероятно, будет работать медленнее в зависимости от микропроцессора. Кроме того, Poly1305 требует выполнения некоторых модульных арифметических операций с большими числами по сравнению со многими хеш-функциями.

Я просто чешу затылок, так как с EtM все в порядке. Я даже нашел черновик IETF AES-CBC-HMAC где то выполняет EtM.Тем не менее, он так и не прошел дальше черновика, что кажется мне странным.

Редактировать: Поскольку были упомянуты наборы CCM Cipher. при работе AES в режиме CTR избегает заполнения оракулов. Он не входит в обязательный набор шифров или один из ДОЛЖЕН реализовать наборы. Видеть: Обязательные к реализации наборы шифров Таким образом, в принципе невозможно использовать преимущества аппаратного обеспечения AES на микро, не имея также GCM. (например, многие серверы отключают CCM по умолчанию, и ни Firefox, ни Chrome не включают CCM). Итак, снова все еще кажется странным, что здесь нет ничего промежуточного, и я действительно не вижу какой-либо веской причины, почему, и режим EtM кажется достойным кандидатом, но он даже не был добавлен в стандарт.

Рейтинг:5
флаг in

Для встраиваемых устройств есть режим СКК, который в основном представляет собой безопасный способ выполнения AES-CBC-MAC + AES-CTR в (излишне сложном, но довольно эффективном) пакетном режиме. Обратите внимание, что это в основном MAC-затем-шифрование, но как часть общего безопасного режима; Атаки оракулов заполнения, безусловно, неприменимы, поскольку режим счетчика не требует заполнения.

Доступны следующие наборы шифров:

  • TLS_AES_128_CCM_SHA256
  • TLS_AES_128_CCM_8_SHA256 (как определено в RFC 6655)

Последний также имеет более эффективную метку аутентификации (относительно размера, а не вычислительной мощности) 8 байт / 64 бита, что должно быть достаточно.

Поэтому я предполагаю, что они не думали, что нужен другой алгоритм, в том числе потому, что есть несколько встроенных систем, которые имеют ускорение SHA-1 или SHA-256.

Примечания:

  • Хэш в конце набора шифров используется только для получения сеансового ключа и тому подобного (PRF в TLS), поэтому он не используется для каждого сообщения.
  • AES в режиме CTR и в CBC-MAC используется только в режиме пересылки/шифрования, поэтому вам не нужна аппаратная поддержка для операции расшифровки.
kelalaka avatar
флаг in
Есть ли конкретная причина для записи AES-CBC-MAC + AES-CTR вместо AES-CTR + AES-CBC-MAC, кроме указания того, что MAC выполняется перед шифрованием?
Maarten Bodewes avatar
флаг in
@kelalaka Нет, я думал, что так будет меньше путаницы.
kelalaka avatar
флаг in
Возможно добавление $$c = \big(\operatorname{AES-CTR}(m)\|(\operatorname{AES-CTR}(m_0) \oplus \operatorname{AES-CBC-MAC}\big(Nonce\mathbin\ |Ассоциированные данные \mathbin\|m) \big)\big)$$ сделают его более ясным или неясным.
флаг cn
Конечно есть КМС. Это нормально, например, если вы управляете сервером, с которым ваше устройство разговаривает, например, запросом API и т. Д. Еще одна вещь, которую я заметил, это то, что на других серверах он часто отключается. Кроме того, chrome и firefox не включают этот набор шифров, ограничивая параметры.
флаг cn
Еще одна вещь, как вы упомянули, CCM - это не EtM, но да, работа AES в основном в качестве потокового шифра позволяет избежать заполнения оракулов. Однако, как я уже упоминал, режимы работы CCM не кажутся широко доступными. По сути, форсирование чего-то вроде ChaCha20-Poly1305 для более широкой совместимости, поскольку GCM потребует умножения без переноса. Это все еще кажется мне странным, поскольку здесь есть пробел. Там, где кажется, что какой-то режим EtM будет более широко включен, и это кажется странным, режимов EtM для TLS 1.3 нет.
Maarten Bodewes avatar
флаг in
Конечно, но неясно, как, например. CBC + HMAC тоже подойдет. Скорее всего, это не будет обязательным набором шифров, поэтому он также будет необязательным. То, что CCM не является EtM, не имеет значения... если оно безопасно. Маловероятно, что кто-то будет реализовывать это как расшифровать, использовать и затем проверить - даже если это возможно.
флаг cn
Что ж, CBC + HMAC — хорошо известная конструкция, и если она работает в конструкции EtM, то можно избежать основных ловушек MAC при шифровании. Не кажется необоснованным, что даже если бы это было необязательным, его все равно включали бы чаще, поскольку это хорошо известная конструкция.

Ответить или комментировать

Большинство людей не понимают, что склонность к познанию нового открывает путь к обучению и улучшает межличностные связи. В исследованиях Элисон, например, хотя люди могли точно вспомнить, сколько вопросов было задано в их разговорах, они не чувствовали интуитивно связи между вопросами и симпатиями. В четырех исследованиях, в которых участники сами участвовали в разговорах или читали стенограммы чужих разговоров, люди, как правило, не осознавали, что задаваемый вопрос повлияет — или повлиял — на уровень дружбы между собеседниками.