Хэш-функции в блокчейне: SHA-256, Keccak и требования к безопасности

Хэш-функции в блокчейне: SHA-256, Keccak и требования к безопасности

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

Также, подпишитесь на наш телеграмм канал - https://t.me/kriptovalyutagpt/ и группу Вконтакте https://vk.com/kriptovalyutadlyanovichkov будет много полезного!

Зачем хэш‑функции нужны блокчейну

Криптографическая хэш‑функция - это детерминированный алгоритм, который преобразует входные данные (транзакции, блоки, сообщения) в строку фиксированной длины - хэш (digest). В блокчейне хэширование обеспечивает:

• Целостность данных: любое изменение байта в транзакции или блоке меняет хэш (классический лавинный эффект).
• Неизменяемость (immutability) цепочки: каждый блок содержит хэш предыдущего блока, формируя связанный список блоков (chain).
• Ускорение проверки: вместо сравнения больших данных сравнивают хэш‑значения.
• Структуру данных Merkle tree (дерево Меркла): хэш‑дерево позволяет быстро доказывать включение транзакции в блок (Merkle proof).
• Механизмы консенсуса: в Proof‑of‑Work (PoW) майнеры подбирают nonce так, чтобы хэш заголовка блока (block header) был меньше целевого значения (target), что выражается через сложность (difficulty).

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

SHA‑256 в блокчейне (Bitcoin и не только)

SHA‑256 - криптографическая хэш‑функция из семейства SHA‑2 (стандартизована NIST, FIPS 180‑4) с выходом 256 бит. В контексте блокчейна она известна прежде всего по Bitcoin:

• В Bitcoin применяется двойное хэширование: SHA-256(SHA-256(data)) (часто пишут SHA‑256d).
• Хэшируют заголовок блока, включающий версию, хэш предыдущего блока, корень Меркла, время (timestamp), target (bits) и nonce.
• Полученный хэш определяет "сложность" нахождения блока и защищает сеть за счет затрат вычислительных ресурсов (майнинг, ASIC‑оборудование).

Сильные стороны SHA‑256:

• Высокая изученность и широкая криптоаналитическая база.
• Хорошая производительность и стабильная реализация во многих языках и библиотеках.
• Стойкость к классическим атакам (при корректном применении) на коллизии и предобраз.

Практический нюанс безопасности: как Merkle–Damgård конструкция, SHA‑256 теоретически подвержена length extension attack при неправильном использовании для "хэш‑аутентификации". Поэтому для MAC используют HMAC‑SHA‑256, а в блокчейн‑протоколах дизайн обычно устроен так, чтобы этот класс атак не давал полезного преимущества (например, четко фиксированные поля, двойное хэширование, разделение доменов и т.п.).

Keccak и Keccak‑256 (Ethereum) vs SHA‑3

Keccak - семейство функций на основе sponge‑конструкции. На базе Keccak был принят стандарт SHA‑3 (NIST, FIPS 202), но важно:

• В Ethereum исторически используется Keccak‑256, который не полностью идентичен стандартизованному SHA3‑256 из‑за отличий в padding/параметрах.
• Поэтому "SHA‑3 в Ethereum" в разговорной речи часто означает именно Keccak‑256.

Где применяется Keccak в Ethereum‑подобных системах:

• Хэширование структур и данных транзакций/блоков.
• Получение идентификаторов, построение деревьев (в Ethereum используются свои структуры, включая Patricia/Merkle‑подходы).
• В вычислениях внутри смарт‑контрактов (например, для коммитментов, доказательств, адресации).

Плюсы Keccak (sponge‑подход):

• Нет классической length extension проблемы как у Merkle–Damgård при наивных схемах.
• Гибкость: можно строить функции с разными длинами выхода (XOF‑режимы типа SHAKE в SHA‑3 семействе).
• Хорошие криптографические свойства при корректных параметрах.

Ключевые требования к безопасности хэш‑функций в блокчейне

Чтобы хэш‑функция считалась криптографически стойкой (а блокчейн - защищенным), обычно требуют:

Стойкость к нахождению предобраза (preimage resistance)

• По заданному хэшу должно быть вычислительно невозможно найти сообщение, дающее этот хэш.

Стойкость ко второму предобразу (second preimage resistance)

• Для данного сообщения m должно быть крайне трудно найти другое m2 ≠ m с тем же хэшем.

Устойчивость к коллизиям (collision resistance)

• Нельзя эффективно найти любые два разных сообщения с одинаковым хэшем.
• Это напрямую связано с атаками "подмены", "фальсификации" и снижением доверия к целостности.

Лавинный эффект и псевдослучайность выходов

• Малое изменение входа ⇒ радикально иной хэш, без "закономерностей".

Детерминированность и стандартизируемость

• Один и тот же вход всегда дает один и тот же результат на всех узлах сети (иначе консенсус невозможен).

Отсутствие "практических" слабостей реализации

• Даже стойкий алгоритм можно сломать плохой реализацией: ошибки в padding, разные endian‑форматы, некорректная сериализация полей, утечки по side‑channel (тайминги), небезопасные зависимости.

Как хэши защищают транзакции и блоки на практике

• Хэш транзакции (txid) выступает как уникальный идентификатор: меняется подпись/вход/выход - меняется txid.
• Дерево Меркла позволяет узлу проверить включение транзакции в блок без скачивания всех транзакций (важно для SPV/легких клиентов).
• Связка блоков через хэши делает подмену истории дорогой: чтобы изменить старый блок, нужно пересчитать все последующие, конкурируя с текущей сетью (в PoW - с суммарным хэшрейтом).

SHA‑256 или Keccak - что "безопаснее"?

В современных условиях и при корректном использовании и SHA‑256, и Keccak‑256 считаются криптографически стойкими для задач блокчейна. Выбор обычно определяется:

• историей и дизайном протокола (Bitcoin → SHA‑256d, Ethereum → Keccak‑256),
• экосистемой и совместимостью библиотек,
• требованиями к производительности и аппаратной реализации (CPU/GPU/ASIC),
• удобством предотвращения классов атак (например, доменное разделение, форматирование данных, "безопасное" хэширование структур).

Частые ошибки разработчиков безопасного применения SHA‑256 / Keccak

Типовые ошибки (что снижает безопасность и повышает уязвимость):

• Путаница SHA3‑256 и Keccak‑256. В Ethereum обычно нужен Keccak‑256, а не стандартизованный SHA3‑256 (разный padding). Ошибка приводит к несовместимости хэшей, адресов, подписей и "неверифицируемым" данным.
• Неоднозначная сериализация данных (encoding). Хэшируют "как получилось": строки, числа, JSON без строгого формата. В результате разные узлы/клиенты могут получить разные хэши.
• Требование: каноническая сериализация (фиксированный порядок полей, длины, endian, отсутствие лишних пробелов/нулей).

"Склейка" полей без разделителей (hash collision by concatenation)

• Пример: hash(a || b) без длины/разделителя может дать неоднозначность ("12"||"3" vs "1"||"23").
• Решение: добавлять длины, типовые теги, использовать ABI/Protobuf/SSZ, либо hash(len(a)||a||len(b)||b).

Отсутствие доменного разделения (domain separation)

• Один и тот же хэш используется для разных типов объектов: транзакция/сообщение/коммитмент. Это открывает путь к "перепутыванию смысла" данных.
• Решение: hash("TX" || data), hash("BLOCK" || data) или стандарты вроде EIP-191/EIP-712.

Использование хэша как "шифрования" или источника случайности

• Хэш‑функция дает необратимость, но не заменяет шифрование. А "случайность" на on-chain данных предсказуема (манипулируема валидатором/майнером).
• Решение: для шифрования - AEAD (например, AES‑GCM/ChaCha20‑Poly1305), для случайности - VRF/commit‑reveal/оракулы.

Неправильное применение SHA‑256 вместо HMAC / KDF

• Делать "подпись" как SHA256(secret || message) - плохая практика (структурные риски, ошибки дизайна).
• Решение: HMAC‑SHA‑256 для MAC, HKDF для производных ключей.

Опираться на tx.origin, block.timestamp, blockhash как на "доказательство" (смарт‑контракты)

• Эти значения ограничены протоколом и частично контролируемы участниками, что рождает атаки (предсказуемость ↔ непредсказуемость).
• Решение: корректные схемы аутентификации и источники энтропии.