Насколько ненадежным будет шифр, основанный на итеративном хешировании?

Мне просто было интересно, как следующая конструкция может быть небезопасной. Я могу сказать, что известные атаки возможны, но я не уверен ни в чем другом.

Пусть пользователь выбирает пароль и хэширует его достаточно большое количество раз с помощью чего-то с устойчивостью к прообразу, например SHA-256. XOR открытого текста с хешем. Снова хешируйте хэш. XOR результата со следующим блоком открытого текста... и так до конца. Как противники смогут это нарушить?

TL;ДР; Небезопасно, не используйте его. Используйте стандарты и известный режим работы.

Ваша конструкция $s_i = H^i(пароль)$ т.е. хешировать пароль $я$ раз, затем используйте выходы $s_i$ для каждого шага x-or с открытым текстом для получения зашифрованного текста; $c_i = p_i \oplus s_i$

Как противники смогут это нарушить?

Есть способы добиться этого

• Угадывающая атака: Если кто-то получает какую-то часть вашего сообщения, например, по крайней мере 256 бит полного блока SHA-256, то остальные сообщения легко расшифровываются. Так здесь нет прямой секретности..

  Нужно посмотреть на эти слайды о Хэш_DRGB увидеть лучший дизайн против государственных компромиссов. При создании псевдослучайной последовательности компрометация текущего состояния не должна привести к утечке других состояний. Главный недостаток предлагаемого проекта заключается в следующем.

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

  Либо нужно менять пароль при каждом шифровании, либо вводить стандартные методы IV для смягчения последствий, иначе гибель!

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

  Вместо этого мы используем случайные ключи, которые либо генерируются локально, либо извлекаются из таких протоколов, как DHKE.

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

  Для локального шифрования обычная практика такова; создание случайного ключа шифрования файлов FEK для каждого файла. Затем, используя пароль пользователя, получите ключ шифрования ключей (KEK) с хорошим PBKDF, например Argon2. С помощью KEK шифруйте и расшифровывайте FEK, а затем шифруйте/дешифруйте файлы. Более подробная информация здесь.

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

• Вы только запросили предварительное сопротивление, однако вы также нужна защита от столкновений. Если в сгенерированном потоке легко могут возникнуть коллизии, то он будет повторяться, и это точка атаки. По крайней мере, ваш поток не будет псевдослучайной последовательностью. К счастью для вас, SHA-256 обладает устойчивостью к коллизиям, а ожидаемые диапазоны циклов огромны;

  Пусть SHA-256 моделируется как однородная случайная функция, тогда вероятность нахождения элемента в цикле равна

  $$\frac{1}{\sqrt{\hspace{0,03 дюйма}2\hspace{-0,05 дюйма}\cdot \hspace{-0,04 дюйма}\pi} \cdot 2^{127}}$$

  Средняя длина цикла с ожидаемым значением для SHA-256 составляет $$2^{127} \sqrt{2\pi}$$ Поэтому вы не боитесь коротких циклов. Ссылка Харрис, 1960 год.

• Ваша схема не имеет защиты Ind-CPA.

Что мы имеем вместо этого?

• У нас есть хорошо известный режим CTR, который может преобразовать любую псевдослучайную функцию (PRF) в схему шифрования с 1979 года. Это основополагающая статья Уитфилда Диффи и Мартина Хеллмана;

  • Конфиденциальность и аутентификация: введение в криптографию в качестве приглашенного доклада на Proceedings of the IEEE, 67 (1979), стр. 397–427.

Это огромное преимущество, поскольку оно позволяет использовать широкий спектр функций, а не только PRP.Режим CTR имеет IV для рандомизации шифрования и обеспечивает вероятностное шифрование. CTR может обеспечить безопасность Ind-CPA.

В настоящее время все шифры в режиме TLS используют внутренний режим CTR, AES-GCM, AES-CCM и ChaCha20-Poly1305.

Заключение

Нет никакого преимущества перед режимом CTR, даже если вы добавите IV в свою схему шифрования и даже решите проблему с паролем и наиболее проблемную часть: угадывающая атака.

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

Теперь вернемся к вашему вопросу, вы сами сказали, что возможна атака известным открытым текстом. И сделать это катастрофически легко.Все, что вам нужно знать, — это один блок обычного текста, чтобы восстановить весь последующий простой текст, открыв хэш в этом блоке. Это намного более низкий уровень безопасности по сравнению с тем, что ожидается от современных шифров, которые предназначены для защиты от злоумышленников, способных выполнять атаки с выбранным открытым текстом или выбранным зашифрованным текстом. Даже не так сложно определить или, по крайней мере, сузить до возможного количество попыток для одного блока открытого текста на основе форматов файлов, небольшого количества доступной информации о владельце файла и т. д., которые можно использовать для расшифровки всего зашифрованного текста.

На самом деле, задолго до того, как я тоже подумал о подобном шифре, но вместо того, чтобы просто хешировать все итеративно, я подумал о том, чтобы сделать xor левой половины хэш-вывода с блоком открытого текста и хешировать правую половину для следующего блока. Это может быть рандомизировано путем смешивания общедоступного случайного числа с ключом. Другим более известным способом является использование хэша в режиме CTR для генерации потока, как мы делаем с блочными шифрами, поскольку режим CTR не требует, чтобы вы могли расшифровать блок. Как отметил kelalaka, он также обеспечивает произвольный доступ.

Но помните, что нельзя показать, что это безопасно в простой модели, и поэтому вы не можете быть полностью уверены в ее безопасности с помощью хеш-функций, таких как SHA-2, которые не были предназначены для использования таким образом. Это требует дополнительного предположения, что ваша хеш-функция достаточно близка к случайному оракулу, чтобы безопасно использовать ее таким образом. И даже если он безопасен с помощью обычных хеш-функций, он, скорее всего, не будет широко использоваться, потому что он будет намного медленнее, чем AES с аппаратной поддержкой или Chacha20 (который также использует режим CTR, как упоминалось выше).