Why AES sucks? Сраный стыд!

https://soatok.blog/2020/05/13/why-aes-gcm-sucks/
Полная ахинея, а не статья. Всё начинается в ней с того, что у AES-128
заявляются безопасность в 128-бит. Но у AES 128-бит размер блока и через
2^64 начинаются коллизии в AES-CBC режиме! Поэтому...

    This is significantly smaller than the 2^128 you expect from AES.

@#$! Какая взаимосвязь то? То, что CBC имеет ограничение на кол-во
обрабатываемых блоков... известно как-бы десятилетиями и всюду и везде в
любом протоколе (нормальном) о них предупреждают. Как решить эту
проблему? Менять ключ не реже чем 2^64 блоков. Проблема решена. Тем
более, что на практике это достаточно большое число чтобы не приходилось
менять чересчур уж часто, как это нужно с 64-бит блочными шифрами. А
автор статьи мешает: безопасность шифра с безопасностью CBC и мешает
сложность атаки и пределы *безопасной* применимости. Да и вообще это
прям что-то явно новое: приравнивать безопасность алгоритма шифрования к
кол-ву блоков которые он может обработать.

Дальше он продолжает развивать свою идею. Оставим это.

Придирается к GHASH конструкции, даже картинку как в Wikipedia поместил
и говорит что сообщения аутентифицируются зашифрованным на ключе нулевым
блоком. Автор наверное слеп и не замечает в самом конце XOR-а с
зашифрованным nonce-ом. А ссылку он приводит на nonce-reuse атаку, не
связанную с проблемой GHASH-а. Да, GCM это не nonce-misuse-resistant
режим, как и тьма других, как это известно с самого их появления. Nonce
должен быть nonce-ом! Если у тебя режим работы и условия использования
такие, что ты не можешь обеспечить его уникальность, то GCM неприменим,
точка. Просто в 99% случаев применения шифрования -- nonce можно сделать
гарантированно неповторяемым.

Далее раздел про короткие nonce. Да, они короткие, делая AES-GCM
применимым только к сессионным достаточно часто меняющимся ключам. Опять
же, это известно любому и в чём проблема то? Хочешь использовать
long-term ключи? Ну так не притворяйся дураком и вырабатывай (HKDF хотя
бы) ключи из long-term-а, а на выработанных уже шифруй в GCM-е. Не, не
спорю что короткие nonce-ы не везде удобны, но так и GCM никто не
предлагает применять для любой задачи на свете.

Ещё автор радуется наличию double ratcheting в Signal. Да, это
действительно хорошая штука. И даже против side-channel атак помогает. И
я осознанно написал "даже", так как это не основное его предназначение.
Но в конце статьи автор умалчивает что XChaCha20-Poly1305 то никакого
ratcheting не содержит... мне кажется что автор считает что у ChaCha20
не возможны side-channel атаки, а ratcheting нужен только для их
предотвращения.

Далее он ведёт речь про "message franking". Я вообще не понимаю какое
это имеет отношение к AEAD режиму и задаче передачи сообщений? Мягко
говоря, это совершенно отдельная задача и на кой чёрт её нам тут решать
то? Ещё автор, похоже, считает что многие любят выбирать ENC + HMAC
конструкции глядя на Signal... мягко говоря, от этой конструкции все
отходят и используют только AEAD, как минимум из-за производительности,
не говоря про удобство (простоту и значит безопасность) и прочее.

В общем заканчивается предложением использовать XChaCha20-Poly1305 "for
encrypting messages under a long-term key". То есть, всё же AES-GCM
обсирался с точки зрения long-term key usage? Об этом явно говорится
только в самом конце статьи. А разве кто-то предлагает использовать
AES-GCM для этой задачи? Но про 2^64 уровень безопасности это полная
ахинея конечно.

Единственное в чём я безоговорочно поддерживаю автора, так это в
предложении использовать *ChaCha20-Poly1305, ибо отсутствие Sbox-ов,
скорость и уровень безопасности там превосходны и, если есть выбор, то
AES я бы тоже не выбрал бы ни за что. Только у меня нет ни одного
сомнения в его безопасности. Сомнения в его корректном применении? Могут
быть. Точно так же, как и могут быть при использовании XChaCha20-Poly1305.
Абсолютно точно такой же не-nonce-misuse-resistant алгоритм. Или автор
предлагает использовать всегда именно X-версию и рандомно генерировать
nonce для каждого пакета?