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

Я некоторое время ломал голову, почему 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 кажется достойным кандидатом, но он даже не был добавлен в стандарт.

Для встраиваемых устройств есть режим СКК, который в основном представляет собой безопасный способ выполнения 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 используется только в режиме пересылки/шифрования, поэтому вам не нужна аппаратная поддержка для операции расшифровки.