1. Одинаковые имена файлов не означают одинаковое содержимое
Если имя и размер загруженного установочного файла совпадают с указанными на странице, легко решить, что загрузка прошла правильно. Однако имя можно изменить, а файлы одинакового размера могут содержать разные данные. И наоборот, копирование фотографии под другим именем не обязательно меняет байты внутри файла. Здесь помогает хеш: содержимое файла обрабатывается заданным алгоритмом и представляется коротким значением. Проверяют не правдоподобие имени, а соответствие полученных байтов надежному эталону. Тот же вопрос возникает при переносе резервной копии на другой накопитель.
SHA-256 создает из входных данных хеш длиной 256 бит. Его обычно записывают 64 шестнадцатеричными цифрами, поскольку каждая такая цифра представляет 4 бита. При увеличении файла длина результата не растет пропорционально его размеру. Одинаковые байты при одном и том же алгоритме дают одинаковый результат. Но число значений ограничено, поэтому коллизии, при которых разные входные данные дают одинаковое значение, в принципе существуют. Практическое средство сравнения следует отличать от математически уникального имени для любого файла. RFC 6234 содержит вычисления хешей, включая SHA-256, и тестовые материалы.
2. Хеш — не шифрование и не уменьшенная копия файла
Знание хеша не дает кнопки расшифровки, восстанавливающей исходный документ или фотографию. Шифрование предусматривает восстановление исходных данных с подходящим ключом, а криптографический хеш не является форматом хранения для такого восстановления. Но это не означает, что публикация только хеша сохраняет любые входные данные в тайне. Если возможных вариантов немного, можно вычислить хеш каждого и сравнить. Поэтому объяснение SHA-256 для проверки файлов нельзя превращать в совет хранить пароли после простого хеширования без дополнительных мер. Проверка целостности, конфиденциальность и хранение паролей предъявляют разные требования.
При обработке всего файла сравниваются не только видимые на экране символы. Даже если предложения выглядят одинаково, различия в переводах строк, кодировке или внутренних метаданных документа могут означать разные байты. Извлеченный из архива файл и сам архив — разные объекты сравнения. После нормализации символов или изменения переводов строк получается хеш уже преобразованных данных. Если распространитель опубликовал значение исходного архива, сначала следует сравнить именно загруженный архив. Это практическое применение различия между отображением и байтами, разобранного в предыдущей статье об Unicode и UTF-8.
3. Сравнивайте загрузку с эталоном для того же алгоритма
Перед проверкой в официальной инструкции разработчика уточняют версию, операционную систему, имя файла и алгоритм хеширования. Значение для другой версии или установщика под другую систему не подходит. В PowerShell команда Get-FileHash -LiteralPath '.\download.zip' -Algorithm SHA256 читает локальный файл и вычисляет его хеш. Она не запускает содержимое указанного пути. Официальная документация Microsoft поясняет, что значение вычисляется по содержимому и одно переименование его не меняет. Имя и путь заменяют на соответствующие реально полученному файлу, а во время вычисления файл не изменяют.
В выводе сравнивают все 64 цифры поля Hash с опубликованным распространителем значением SHA-256. Совпадения нескольких первых или последних цифр недостаточно. Заглавные и строчные латинские буквы в шестнадцатеричной записи обозначают одинаковые числа, но при посторонних символах или недостаточной длине сначала проверяют скопированное значение. Совпадение поддерживает вывод о соответствии полученных байтов доверенному эталону. Оно не проверяет достоверность документа, качество программы или вредоносное поведение. Если сам эталонный файл содержит проблему, точная копия даст тот же хеш. Успешное вычисление и допустимость использования файла требуют отдельных оценок.
4. Несовпадение требует выяснения причины, а не доказывает атаку
Предположим, вчера загруженный дистрибутив не совпал со значением из сегодняшней инструкции. Это поясняющий пример, а не описание реального инцидента. Сначала проверяют, относится ли инструкция к той же версии, не был ли выбран файл для другого устройства и завершилась ли загрузка до вычисления. Возможно, вместо архива проверили извлеченный файл или редактор заново сохранил документ. Изменение объекта сравнения следует отличать от изменения содержимого при передаче или хранении. Само несовпадение не показывает, кто, когда и что изменил.
Установочный файл с несовпавшим хешем не запускают ради проверки: сначала заново сверяют официальную инструкцию и эталон, затем сравнивают свежую загрузку. Если расхождение сохраняется, полезно проверить исправления или канал поддержки распространителя и сохранить результат. В запись включают время проверки, адрес источника, версию файла, алгоритм и вычисленное значение. Повторяемость результата указывает, что текущий локальный файл прочитан одинаковым способом, но не исправляет ошибку опубликованного эталона или проблему пути распространения. Перезапись эталонной записи ожидаемым значением лишает дальнейшую проверку основания для выявления изменений.
5. Почему эталону можно доверять и что дает цифровая подпись
Если атакующий может заменить и файл, и опубликованный рядом хеш, он может вычислить хеш измененного файла и представить его новым эталоном. NIST SP 800-175B объясняет это ограничение использования одного хеша без ключа или подписи. Получение значения с HTTPS-страницы по официальному адресу помогает проверять источник и путь передачи, но не исключает компрометацию самого сервера распространения. Важна не внушительная длина строки, а происхождение эталона и процедура доверия к нему. Совпадение двух значений, скопированных с одного экрана, само по себе не устанавливает личность разработчика.
Цифровая подпись позволяет проверять связь подписи и данных, используя, например, открытый ключ, полученный надежным способом. Если распространитель предлагает процедуру проверки, следуют официальным указаниям, включая подтверждение владельца ключа и его отпечатка. Безусловное доверие впервые увиденному ключу рядом с файлом неизвестного происхождения не решает проблему исходного доверия. HMAC с общим секретным ключом — тоже средство аутентификации, отличное от обычного хеша, но его нельзя произвольно добавить к любой загрузке и считать вопрос решенным. Действительная подпись не доказывает отсутствие дефектов в программе или истинность документа. Совпадение байтов, установление источника и оценка содержания связаны, но требуют собственных оснований.
6. В резервном копировании и совместной работе фиксируйте границы сравнения
При резервном копировании личных фотографий сохраненный SHA-256 оригинала помогает выявлять изменения при переносе, если сравнить его с копией. Список эталонов также сохраняют так, чтобы он не исчез и не был перезаписан вместе с оригиналами. Если фотопрограмма заново записала ориентацию или метаданные съемки, хеш может измениться при почти неизменном изображении. Поэтому сначала определяют цель: сохранение точных байтов или смысловое соответствие отредактированной фотографии. Для проверки целой папки недостаточно одного файлового хеша: нужны список включенных файлов, относительные пути и значение каждого файла.
В совместном рецензировании документов хеш может фиксировать проверенную редакцию. Но совпадение хеша не заменяет свидетельство того, что кто-то прочитал весь текст или сверил перевод. Сначала записывают, что, когда и каким способом проверили, а затем связывают запись со значением файла. Иллюстрация этой статьи — собственная поясняющая схема сравнения байтов, происхождения эталона и границ проверки, а не измерение или сертификат. Проверяя файл, последовательно фиксируйте объект и алгоритм, источник эталона и пределы выводов. Тогда следующий участник сможет повторить процедуру без преувеличения значения совпадений и расхождений.