Минусы потоковых шифров, основанных на хеш-функциях

В ответ здесь кто-то упоминает:

если у вас есть хеш-функция с полномочиями оракула, то довольно легко сгенерировать псевдослучайный поток из секретного ключа путем хеширования K||n, где K — секретный ключ, а n — счетчик. Совершая XOR этого зависящего от ключа псевдослучайного потока с данными для шифрования, вы получаете потоковый шифр.

В том же посте есть и эта часть, касающаяся использования криптографических хеш-функций для создания потокового шифра:

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

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

Действительно ли единственная проблема заключается в том, что «не доказано, что этих условий достаточно для построения потокового шифра»? Какие еще проблемы с потоковыми шифрами возникают из-за хеш-функций? Наверное, они менее безопасны? Они, наверное, медленнее? Возможно, они используют слишком много памяти? Просто исследуются другие алгоритмы шифрования, которые обещают лучшие результаты?

Я бы предположил, что хэш-функция с большим размером блока имеет то преимущество, что можно использовать более длинные ключи или более длинные одноразовые номера. Для SHA-512 можно использовать ключ длиной 384 бита и одноразовый номер длиной 128 бит. Другой возможностью было бы продолжать использовать 256-битные ключи, использовать 128-битные одноразовые номера и иметь лучший максимальный размер сообщения 2 ^ 128 блоков (или 2 ^ 137 бит для SHA-512) по сравнению с ~ 2 ^ 39 бит для AES-GCM с только 96-битные одноразовые номера (что, на мой взгляд, было бы хорошей целью).

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

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

Есть некоторые проблемы с тем, как был представлен ваш вопрос. Есть одноразовый номер, счетчик и ключ. Вы говорите об одноразовых значениях ниже, но не о счетчике и приведенном вами уравнении. $Ч(к\mathbin\|n)$ из ответа есть счетчик, но нет одноразового номера, поэтому вы не дали понять, как вы их используете.

Во всяком случае, насколько нам известно, $H(k\mathbin\|n\mathbin\|\text{ctr})$ куда $n$ и $\текст{ктр}$ соответственно, nonce и counter могут быть хорошим генератором потока для большинства хеш-функций, я думаю, пока $к$, $n$ и $\текст{ктр}$ все имеют фиксированную длину (вам не нужно беспокоиться об атаках типа расширения длины для ввода фиксированной длины). Но в более общем случае вы должны использовать функции, которые считаются псевдослучайными функциями (например, HMAC) для разумной гарантии безопасности, если вы хотите использовать поток на основе хэша. Как в $\operatorname{HMAC}_k(n\mathbin\|\text{ctr})$ . И поскольку HMAC использует двойное хэширование, а блочные шифры, такие как AES, имеют высокую оптимизацию, я полагаю, что он не обеспечивает той производительности, которую обеспечивают современные потоки (чача, AES-CTR/GCM), даже если он достаточно безопасен.