Если уже есть средства для аутентификации открытого текста, то действительно можно пропустить аутентификацию открытого текста или зашифрованного текста другими средствами.
Есть, конечно, некоторые уловки.
Прежде всего, открытый текст ни в коем случае не должен использоваться до проверки аутентифицированного хеш-значения.Если это не так, злоумышленник может изменить открытый текст, что означает, что сторона подвергается многим типам атак, включая оракул открытого текста или, возможно, внедрение ошибок.
Кроме того, реализация не должна предоставлять никакой информации о процессе расшифровки. Если это так, то реализация может подвергнуться атакам по сторонним каналам. Хуже, если, например. Используется CBC, затем применяются оракулы заполнения. Поэтому имеет смысл использовать AES-CTR или потоковый шифр, такой как ChaCha20.
При использовании режима аутентификации можно избежать двух последних ошибок проектирования/реализации. Таким образом, режим аутентификации может быть полезен, даже если ключу нельзя доверять. Одним из недостатков является то, что другие разработчики могут предположить, что аутентифицированный режим действительно обеспечивает требуемую аутентификацию, и начать использовать открытый текст, даже если сообщения еще не аутентифицированы.
Лично я бы не стал использовать для этого режим аутентификации.
Обратите внимание, что обработка IV не указана в протоколе, который вы описываете. Нет необходимости быть частью хэша, если он защищает открытый текст, а не зашифрованный текст. Однако следует убедиться, что он уникален для каждого сообщения, зашифрованного одним и тем же ключом (а если вы используете режим CBC, непредсказуем).
Я также не вижу, восприимчив ли протокол к атакам воспроизведения и атакам с угадыванием открытого текста, если аутентифицированный хэш используется как для идентификации, так и для аутентификации.