Предоставляет ли AEAD какие-либо преимущества по сравнению с необработанным шифром в этом параметре?

Я работаю над хранилищем криптографических данных, где необходимо идентифицировать большие двоичные объекты и ссылаться на них с помощью хэша зашифрованных данных. Подумайте о дереве Меркла с зашифрованными узлами. В таких условиях, когда хэш уже устанавливает подлинность (при условии, что сама хеш-функция не нарушена), есть ли смысл использовать AEAD, а не просто использовать шифр напрямую?

Я считаю, что это отличается от классической темы «зашифровать, а затем MAC», потому что в большом двоичном объекте не хранится хэш или MAC для его аутентификации. Скорее, хэш — это внешняя ссылка из другого места, которая уже аутентифицирована (не подлежит предупреждению злоумышленником).

Еще одна деталь, которую я изначально опустил, думая, что она не имеет значения, но задним числом кажется, что она проясняет проблему: нет предварительно общего симметричного ключа; ключ, который можно использовать в необработанном шифре или AEAD, является ключом, полученным из эфемерного секрета и открытого ключа принимающей стороны через ECDH. Таким образом, любой злоумышленник, знающий открытый ключ, может создать большой двоичный объект с действительным тегом AEAD, используя свой собственный эфемерный секрет. Однако если предположить, что хэш-функция не нарушена, такой большой двоичный объект не будет хеширован до значения, ожидаемого принимающей стороной, и, следовательно, никогда не будет использоваться.

Если уже есть средства для аутентификации открытого текста, то действительно можно пропустить аутентификацию открытого текста или зашифрованного текста другими средствами.

Есть, конечно, некоторые уловки.

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

Кроме того, реализация не должна предоставлять никакой информации о процессе расшифровки. Если это так, то реализация может подвергнуться атакам по сторонним каналам. Хуже, если, например. Используется CBC, затем применяются оракулы заполнения. Поэтому имеет смысл использовать AES-CTR или потоковый шифр, такой как ChaCha20.

При использовании режима аутентификации можно избежать двух последних ошибок проектирования/реализации. Таким образом, режим аутентификации может быть полезен, даже если ключу нельзя доверять. Одним из недостатков является то, что другие разработчики могут предположить, что аутентифицированный режим действительно обеспечивает требуемую аутентификацию, и начать использовать открытый текст, даже если сообщения еще не аутентифицированы.

Лично я бы не стал использовать для этого режим аутентификации.

Обратите внимание, что обработка IV не указана в протоколе, который вы описываете. Нет необходимости быть частью хэша, если он защищает открытый текст, а не зашифрованный текст. Однако следует убедиться, что он уникален для каждого сообщения, зашифрованного одним и тем же ключом (а если вы используете режим CBC, непредсказуем).

Я также не вижу, восприимчив ли протокол к атакам воспроизведения и атакам с угадыванием открытого текста, если аутентифицированный хэш используется как для идентификации, так и для аутентификации.

Хэш устанавливает целостность, а не подлинность. Тег AEAD или MAC зашифрованного текста устанавливает как целостность, так и подлинность.

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

Если хэш представляет собой открытый текст, вы получаете те же недостатки, что и в схемах «MAC-затем-шифрование», когда вы нарушаете принцип криптографической гибели.