---
title: "Криптографические хеш-функции"
description: "Ориентированное на проверку руководство по криптографическим хеш-функциям: свойства безопасности, кодирование байтов, SHA-2, SHA-3, Keccak, применение в блокчейнах и риски реализации."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Криптографические хеш-функции
> Материал предназначен исключительно для обучения и не является инвестиционной рекомендацией или руководством по реализации криптографии. Совпадение дайджеста само по себе не доказывает подлинность, право собственности, авторизацию, финальность или доступность данных.
## Краткий ответ
Криптографическая хеш-функция детерминированно преобразует сообщение, представленное байтами, в дайджест с заданной длиной результата. Для хеша фиксированной длины в `n` бит основное соотношение имеет вид:
`h = H(m), where h is in {0,1}^n`
Одинаковые байты и алгоритм дают одинаковый дайджест. Изменение одного входного бита должно непредсказуемо менять множество выходных битов, однако этот лавинный эффект сам по себе не определяет безопасность. Основные требования безопасности: **стойкость к нахождению прообраза** (по известному дайджесту практически невозможно найти породивший его вход), **стойкость к нахождению второго прообраза** (для известного входа практически невозможно найти другой вход с тем же дайджестом) и **стойкость к коллизиям** (практически невозможно найти любые два разных входа с одинаковым дайджестом).
Хеширование не является шифрованием: ключа расшифрования нет, и восстановление входных данных не гарантируется. Поскольку бесконечное множество возможных сообщений отображается в конечное пространство результатов, коллизии неизбежны; безопасность означает, что для выбранных алгоритма и длины результата найти пригодную для атаки коллизию вычислительно неосуществимо.
Сам по себе дайджест также не подтверждает подлинность. Повторное вычисление хеша файла выявляет несовпадение лишь тогда, когда ожидаемый дайджест и алгоритм получены по доверенному каналу. Более сильные гарантии протоколы получают, сочетая хеши с подписями, кодами аутентификации сообщений, аутентифицированными структурами данных, правилами консенсуса или доказательством работы.
## Как это работает
1. **Определите точную последовательность байтов.** Кодировка текста, регистр, пробелы, порядок полей, представление целых чисел, префиксы длины и сериализация влияют на `m`. Протокол должен задавать каноническое кодирование и связывать хеш с конкретными алгоритмом, версией, сетью и назначением.
2. **Выполните заданное преобразование.** SHA-256 предварительно обрабатывает сообщение ограниченной длины, делит его на блоки и итеративно обновляет внутреннее состояние. SHA3-256 использует губчатую конструкцию на основе KECCAK. Обе функции возвращают 256-битные дайджесты, но являются разными и не дают взаимозаменяемых результатов.
3. **Оценивайте безопасность по требуемому свойству.** Для идеального `n`-битного хеша полный поиск прообраза требует примерно `2^n` вычислений, а полный поиск коллизии — примерно `2^(n/2)` из-за парадокса дней рождения. Одной длины результата недостаточно, если алгоритм взломан, дайджест усечен или окружающий протокол содержит недостатки.
4. **Стройте протокол вокруг дайджеста.** Схема цифровой подписи может подписывать дайджест сообщения; HMAC добавляет секретный ключ для аутентификации сообщений; дерево Меркла связывает множество листьев одним корнем; а при доказательстве работы заголовки блоков-кандидатов хешируются многократно, пока дайджест не удовлетворит целевому значению. Эти конструкции дают разные гарантии.
5. **Используйте точную функцию конкретной цепочки.** Заголовки блоков и узлы Меркла в Bitcoin используют двойной SHA-256 с заданным порядком байтов. Исполнительный уровень Ethereum использует Keccak-256 из версии KECCAK до стандартизации, а не стандартизированный SHA3-256. Поэтому обозначения вроде «256-битный хеш» недостаточно для проверки.
6. **Прежде чем делать выводы, проверьте контекст.** Уточните источник ожидаемого дайджеста, идентификатор алгоритма, кодирование байтов, домен или цепочку, ссылку на блок и состояние, статус подтверждения и наличие усечения. Правильное вычисление в неверном контексте все равно означает неудачную проверку.
## Разбор примеров
- **Незначительное изменение входных данных.** SHA-256 пяти байтов UTF-8 для `hello` равен `2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824`. Если заменить первый байт прописной буквой `H`, получится `185f8db32271fe25f561a6fc938b2e264306ec304eda518007d1764826381969`. По различающимся дайджестам нельзя определить, какой байт изменился.
- **Криптографическая стойкость не во всех моделях атаки равна длине дайджеста.** Идеальный 256-битный хеш требует примерно `2^256` операций для поиска прообраза, но `2^128` операций для поиска коллизии. Это различие важно, когда протокол полагается на стойкость к коллизиям, как часто происходит в процессах цифровой подписи.
- **Доказательство Меркла подтверждает включение относительно одного корня.** Проверяющая сторона хеширует закодированный лист с каждым предоставленным соседним узлом в заданном порядке, пока не восстановит зафиксированный корень. Совпадение не доказывает, что корень финализирован, данные листа истинны или пропущенные данные доступны.
- **Доказательство работы добавляет правило целевого значения.** Bitcoin признает заголовок-кандидат действительным, только если значение его двойного SHA-256, истолкованное по правилам консенсуса, меньше закодированной цели или равно ей. Дайджест не становится более стойким к коллизиям из-за того, что майнеры выполнили больше работы.
## Риски
- Использование устаревшего или неподходящего алгоритма, особенно SHA-1 там, где требуется стойкость к коллизиям.
- Ошибочное отождествление SHA3-256, Keccak-256, SHA-256, двойного SHA-256 и по-разному усеченных вариантов.
- Хеширование отображаемого текста вместо канонических байтов либо игнорирование нормализации Unicode, пробелов, порядка байтов, порядка полей и кодирования длины.
- Загрузка файла и ожидаемого дайджеста из одного и того же скомпрометированного источника, что не дает независимой проверки целостности.
- Использование быстрой хеш-функции общего назначения непосредственно для хранения паролей вместо специализированной схемы хеширования паролей с солью и подходящим фактором сложности.
- Использование `H(secret || message)` как самодельного кода аутентификации: некоторые итеративные хеш-конструкции допускают атаки с продолжением сообщения, тогда как HMAC специально разработан для аутентификации с ключом.
- Усечение дайджестов без расчета итоговой стойкости к коллизиям и нахождению прообраза с учетом масштаба протокола и его модели угроз.
- Повторное использование одного кодирования в разных протоколах без разделения доменов, из-за чего действительный в одном контексте дайджест можно истолковать в другом.
- Предположение, что хеш транзакции доказывает подтверждение, финальность, успешное исполнение, право собственности или отсутствие реорганизации цепочки.
- Предположение, что хеш содержимого гарантирует возможность получить соответствующие данные: обязательство может оставаться действительным даже после исчезновения всех доступных копий.
- Сравнение строк в обозревателях без проверки порядка байтов, правил префиксов, сериализации и того, не отображает ли интерфейс внутренний идентификатор иначе.
- Самостоятельная реализация криптографических примитивов без стандартных тестовых векторов, поддерживаемых библиотек, независимой проверки и процедур обновления.
## Распространенные заблуждения
- **Хеш — это зашифрованные данные.** Шифрование обратимо при наличии нужного ключа; криптографический хеш представляет собой односторонний дайджест без операции расшифрования.
- **Разные входные данные никогда не могут иметь одинаковый дайджест.** Для результата фиксированной длины коллизии неизбежны. Безопасная конструкция делает их поиск и эксплуатацию практически неосуществимыми.
- **256-битный дайджест всегда обеспечивает 256 бит безопасности.** Для идеального 256-битного хеша общая стойкость к коллизиям составляет около 128 бит, а решения на уровне протокола могут снизить ее еще больше.
- **Совпадение хешей доказывает, кто создал сообщение.** В обычном хеше нет секрета, и он не аутентифицирует отправителя; если важно происхождение, используйте подпись или подходящий MAC.
- **Keccak-256 и SHA3-256 — два названия одной функции.** Они основаны на тесно связанных конструкциях, но используют разные параметры стандартизации и дают разные дайджесты.
- **Хеш транзакции в блокчейне доказывает завершение расчета.** Он идентифицирует закодированные данные транзакции; включение в цепочку, состояние исполнения, подтверждения и финальность — отдельные факты.
## Связанные темы
- [Блокчейн](/ru/crypto/blockchain/)
- [Трилемма блокчейна](/ru/crypto/blockchain-trilemma/)
- [Дерево Меркла](/ru/crypto/merkle-tree/)
- [Доказательство работы](/ru/crypto/proof-of-work/)
## Источники
- [Хеш-функции](https://csrc.nist.gov/projects/hash-functions) - NIST (дата обращения: 2026-08-20)
- [Стандарт безопасного хеширования (SHS)](https://doi.org/10.6028/NIST.FIPS.180-4) - NIST (дата обращения: 2026-08-20)
- [Стандарт SHA-3: хеш-функции и функции с расширяемым выходом на основе перестановок](https://doi.org/10.6028/NIST.FIPS.202) - NIST (дата обращения: 2026-08-20)
- [Справочник разработчика Bitcoin: цепочка блоков](https://developer.bitcoin.org/reference/block_chain.html) - Bitcoin.org (дата обращения: 2026-08-20)
- [Желтая книга Ethereum](https://ethereum.github.io/yellowpaper/paper.pdf) - Ethereum (дата обращения: 2026-08-20)
Source: https://wiki.fcontext.com/ru/crypto/cryptographic-hash/index.mdx