Хэш с ключом не подвержен коллизиям / парадоксу дня рождения, поскольку у злоумышленника нет ключа; из-за этого вы не можете выполнять какие-либо предварительные вычисления и создавать набор известных хэшей (ну, вы могли бы, если бы у вас был Oracle с ключом, но в этом случае Oracle будет подписывать доставленные ему случайные данные).
Таким образом, вы недооцениваете безопасность, предлагаемую HMAC; в большинстве случаев он предлагает безопасность, которая примерно равна выходному размеру/размеру ключа. Смотрите также keylength.com/рекомендации NIST например (вам нужно посмотреть «Hash (B)» для HMAC в таблице).
Однако вы используете у = SHA384(ш). Теперь, если злоумышленник может попытаться создать коллизию для определенных значений ж, что будет означать, что коллизия хэшей используется во входных данных HMAC, что, конечно же, также приведет к тому же значению HMAC. Так что здесь применяется ограничение по дню рождения.
Так что да, в этом случае вы можете попробовать использовать SHA-384 или SHA-512 (поскольку атаки с расширением длины не приведут к коллизии, так что это не по теме). SHA-384 можно использовать, если вы подозреваете, что при использовании SHA-512 требуется еще один блок хеширования; Тогда SHA-384 может быть немного более эффективным, если такая эффективность вообще требуется.
Однако обратите внимание, что мы обычно предполагаем, что SHA-256 уже имеет мощность 128 бит даже при предполагаемых атаках дня рождения, поэтому даже в этом случае нет острой необходимости использовать SHA-384.
