Перейти к содержанию
Financial Context Wiki

Криптографические хеш-функции

Ориентированное на проверку руководство по криптографическим хеш-функциям: свойства безопасности, кодирование байтов, SHA-2, SHA-3, Keccak, применение в блокчейнах и риски реализации.

Обновлено

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

Краткий ответ

Криптографическая хеш-функция детерминированно преобразует сообщение, представленное байтами, в дайджест с заданной длиной результата. Для хеша фиксированной длины в 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 — два названия одной функции. Они основаны на тесно связанных конструкциях, но используют разные параметры стандартизации и дают разные дайджесты.
  • Хеш транзакции в блокчейне доказывает завершение расчета. Он идентифицирует закодированные данные транзакции; включение в цепочку, состояние исполнения, подтверждения и финальность — отдельные факты.

Связанные темы

Источники

Навигация

Поиск по вики...