Какие свойства и требования предъявляются к криптографическим хэш-функциям?

В DevOps мы используем хэш-функции для обеспечения целостности данных, хранения паролей и создания уникальных идентификаторов (например, для Docker-образов). К надежным хэш-функциям (таким как SHA-256, SHA-512) предъявляются строгие требования:

1. Детерминированность: Один и тот же вход всегда дает одинаковый хэш. Это фундаментально для проверки целостности файлов. Например, скачивая дистрибутив, я сверяю его хэш с опубликованным:

   echo "aec070645fe53ee3b3763059376134f058cc337247c978add178b6ccdfb0019f  terraform.zip" | sha256sum -c

2. Быстрота вычисления: Хэш должен вычисляться эффективно даже для больших объемов данных (файлов, образов дисков).

3. Устойчивость к коллизиям: Крайне сложно (практически невозможно) найти два разных входных сообщения, дающих одинаковый хэш. Падение этого свойства, как у MD5 и SHA-1, делает функцию непригодной для безопасности.

4. Лавинный эффект: Минимальное изменение во входных данных (один бит) должно полностью изменять выходной хэш. Это видно на примере:

   echo -n "hello" | sha256sum
   # 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824
   echo -n "hellp" | sha256sum
   # 5994471abb01112afcc18159f6cc74b4f511b99806da59b3caf5a9c173cacfc5

5. Необратимость (свойство прообраза): По данному хэшу должно быть вычислительно неосуществимо восстановить исходные данные. Это критично для хранения паролей. Мы никогда не храним пароли в открытом виде, только их хэши, полученные с помощью специальных медленных функций с "солью" (например, bcrypt, argon2).

Практическое применение в DevOps:

• Целостность артефактов: Хэши в package-lock.json, Pipfile.lock, Docker-образов (digest).
• Безопасность: Хэширование секретов, сертификатов.
• Идентификация: Git-коммиты идентифицируются по SHA-1 хэшу (сейчас идет переход на SHA-256).