Как проверить файл контрольной суммой: SHA-256 и SHA-512 на практике

Образ системы весом в несколько гигабайт скачался на 99 %, интернет моргнул, и теперь непонятно: файл целый или последний мегабайт превратился в нули. Или другой случай: установщик скачан с зеркала, и хочется знать, что внутри ровно то, что выложил издатель, а не то, что подсунул кто-то на промежуточном сервере. Оба вопроса решает одна и та же процедура: посчитать контрольную сумму файла и сверить её с суммой, опубликованной издателем. На это уходит минута, и устанавливать ничего не нужно: в Windows, Linux и macOS инструменты для подсчёта уже встроены. Ниже вся процедура по шагам, разбор несовпадений и объяснение, почему для проверки скачанного берут SHA-256, а не MD5.

Что доказывает контрольная сумма

Контрольная сумма это отпечаток файла, посчитанный хеш-функцией. У отпечатка два ключевых свойства. Первое: длина всегда одинаковая. SHA-256 от файла любого размера, хоть двух мегабайт, хоть сорока гигабайт, даёт строку из 64 шестнадцатеричных символов. Второе: отпечаток привязан к содержимому. Изменение одного байта в середине файла меняет сумму полностью, и предсказать, как именно она изменится, невозможно. Откуда берутся эти свойства, мы разбирали в статье про хеши MD5 и SHA-256, здесь сосредоточимся на самой процедуре.

Сразу договоримся о пределах применимости. От обрыва связи и битой загрузки сверка защищает надёжно: если файл пришёл с ошибкой, суммы почти наверняка не сойдутся. От целенаправленной подмены защита работает при одном условии: сумму вы взяли не там же, где и сам файл. Это не формальность, а главное правило всей процедуры, к нему вернёмся в разделе про несовпадения.

Где издатель публикует контрольные суммы

Сумму ищут рядом с файлом, обычно в тех же местах, где лежит сама загрузка:

• на странице загрузки рядом с кнопкой скачивания, часто мелким текстом или в раскрывающемся блоке с техническими деталями;
• отдельным файлом в том же каталоге: у образа disk-image.iso рядом лежит disk-image.iso.sha256 или файл SHA256SUMS со списком всех сумм релиза;
• на странице релиза в GitHub: суммы публикуют в описании релиза или прикладывают файлом к списку ассетов;
• в документации или письме, если файл передаётся индивидуально: сумму прикладывают к сообщению отдельно от файла.

Расширение файла подсказывает алгоритм: .sha256 это SHA-256, .sha512 это SHA-512, .md5 это MD5. А вот файл с расширением .sig или .asc это не контрольная сумма, а криптографическая подпись: её проверяют публичным ключом издателя, и это отдельная, более сильная схема. Сама идея подписи разобрана в статье про HMAC и подписи API-запросов; для типовой проверки скачиваний достаточно суммы.

Считаем сумму: Windows, Linux и macOS

Windows: certutil без установки

Утилита certutil есть в любой современной Windows, а опция -hashfile доступна начиная с Windows 7. Откройте обычную командную строку, права администратора не нужны, и выполните:

certutil -hashfile C:\Users\you\Downloads\disk-image.iso SHA256

// вывод в русской Windows:
Хэш SHA256 C:\Users\you\Downloads\disk-image.iso:
f0a72cdc34ec5494579cba7dceac29458eb1d83d2d51e6656a822ae904352310
CertUtil: -hashfile — команда успешно выполнена.

Нужная строка одна, вторая сверху: 64 шестнадцатеричных символа сразу после заголовка «Хэш SHA256» (в английской Windows заголовок выглядит как SHA256 hash of file). В некоторых старых версиях утилита печатает хеш группами по два символа с пробелами: перед сравнением пробелы убирают. Строки про успешное выполнение команды не несут информации и игнорируются.

Второй встроенный вариант это PowerShell: команда Get-FileHash делает то же самое и печатает сумму в верхнем регистре. Регистр не влияет на результат: F0A72CDC и f0a72cdc это одна и та же сумма, hex-символы сравниваются без учёта регистра. Приводите обе строки к одному виду перед сверкой, и разница в написании перестанет сбивать с толку.

Linux и macOS: sha256sum и shasum

В Linux утилита sha256sum входит в состав coreutils и есть в любом дистрибутиве. На macOS её роль выполняет shasum с флагом алгоритма:

$ sha256sum checksum-demo.txt
f0a72cdc34ec5494579cba7dceac29458eb1d83d2d51e6656a822ae904352310  checksum-demo.txt

$ shasum -a 256 checksum-demo.txt     # macOS
f0a72cdc34ec5494579cba7dceac29458eb1d83d2d51e6656a822ae904352310  checksum-demo.txt

Вывод состоит из двух частей: слева сама сумма, справа имя файла, между ними два пробела. Формат не случаен: он совпадает с форматом файлов SHA256SUMS, благодаря чему автоматическая проверка из следующего раздела работает без преобразований. Для SHA-512 команды меняют суффикс: sha512sum или shasum -a 512.

Сверка: глазами или машиной

Ручной способ выглядит так: скопируйте сумму со страницы издателя и вычисленную сумму в соседние строки любого редактора и сравните. Проблема в том, что 64 символа глазами сравниваются утомительно, а ошибиться легко: первые двадцать символов совпали, глаз расслабился, и различие в хвосте никто не заметил. Если сравниваете вручную, вставляйте строки друг под другом в редакторе с подсветкой различий.

Машина справляется лучше, и готовый формат для неё уже существует. Издатель выкладывает файл SHA256SUMS, где каждая строка это сумма, два пробела и имя файла. Положите такой файл в каталог с загрузками и выполните одну команду:

$ cat SHA256SUMS
f0a72cdc34ec5494579cba7dceac29458eb1d83d2d51e6656a822ae904352310  checksum-demo.txt

$ sha256sum -c SHA256SUMS
checksum-demo.txt: OK

# а если файл на диске повреждён:
checksum-demo.txt: FAILED
sha256sum: WARNING: 1 computed checksum did NOT match

Команда пересчитает все суммы из списка и напечатает вердикт напротив каждого файла. Любая строка FAILED означает: содержимое файла отличается от того, над которым считалась опубликованная сумма. Обратите внимание на типичную мелочь: имя файла в SHA256SUMS должно совпадать с именем на диске вплоть до регистра букв, иначе утилита сообщит, что файла нет, а это вердикт другого рода, не то же самое, что несовпадение суммы.

Контрольный пример, который можно повторить

Возьмём маленький текстовый файл checksum-demo.txt, чтобы пройти всю процедуру за минуту и увидеть своими глазами, как выглядит порча данных. В файле три строки, переводы строк в формате Unix и завершающий перевод строки в конце файла, всего 60 байт:

ToolBox Pro checksum demo file
version 1.0
all bytes intact

SHA-256 = f0a72cdc34ec5494579cba7dceac29458eb1d83d2d51e6656a822ae904352310
SHA-512 = 4194d2873450f9d13dfae599626c6f96a59cfa3b30447cb7fcb1df4ad7ba9e09743cd0c0cdc2a4d330a97a4de6d7f9fac24b65467c5579d6e9824dc2da85203a
MD5     = 0e85fcf22e3f2a4a3685bc7513e2fe5a

Создайте файл с таким содержимым в любом редакторе и посчитайте сумму одной из команд выше. Заметьте зависимость от байтов, а не от видимого текста: если сохранить файл с переводами строк Windows (CRLF) или без завершающего перевода строки, суммы получатся другими при том же тексте на экране. Это не ошибка алгоритма, а его точное поведение: он честно отвечает за байты, которые ему дали.

Теперь сымитируем порчу: поменяем в средней строке 1.0 на 1.1, то есть ровно один байт. Новая SHA-256 выглядит так: 4c2284d24ada49e88d696a3b96d83aeaaf513ee5abe300d6e133ccea5c752080. Никакого узнаваемого куска прежней суммы в ней нет, и предугадать, какие позиции изменятся и как, невозможно. У реального образа, оборванного посередине загрузки, отличий будут тысячи, а не один байт, но вывод тот же: сверка ловит повреждение всегда.

Чем SHA-512 отличается в процедуре

Ничем, кроме имени алгоритма и длины строки. SHA-512 выдаёт 128 шестнадцатеричных символов вместо 64 и на современных 64-битных процессорах нередко считается даже быстрее, потому что алгоритм оперирует 64-битными словами. Команды знакомые, меняется имя: certutil -hashfile файл SHA512, sha512sum файл, shasum -a 512 файл.

Издатели часто публикуют обе суммы рядом, и у новичка возникает вопрос, какую сверять. Ответ: любую, но ту, для которой у вас есть опубликованное значение. Нельзя посчитать SHA-256 локально и сравнить с SHA-512 на странице: разные длины и разные алгоритмы. И нельзя считать одну сумму основной, а вторую запасной: обе посчитаны от одного файла, и сходиться должны обе.

Почему MD5 и CRC32 не подходят для проверки скачанного

Обе старые суммы решают задачу «файл не побился по дороге», но не задачу «файл не подменили», и механизмы у них разные:

• CRC32 это 32-битная сумма из мира передачи данных: её придумали для ловли случайных сбоев канала, где вероятность пропустить повреждение один случай на четыре миллиарда выглядит приемлемо. Атакующему подобрать второй файл с той же CRC32 не составляет труда, а 32 бита перебираются на обычном железе за секунды;
• MD5 сильнее CRC32, но сломан намеренно: пары разных файлов с одинаковым MD5 изготавливают специально, и история это подтвердила. В 2012 году вредоносный Flame подделал сертификат цифровой подписи Microsoft, использовав сконструированную коллизию MD5;
• SHA-256 практических коллизий на сегодня не имеет и остаётся стандартом для проверки загрузок; SHA-512 даёт тот же уровень доверия с запасом по длине выхода.

Если издатель публикует только MD5, сверяться всё равно стоит: от битой загрузки старая сумма защищает исправно, а случайное совпадение у повреждённого файла маловероятно. Но границу помните: подмену файла вместе с суммой MD5 не заметит, поэтому для критичных загрузок ищите источник, публикующий SHA-256 или подпись.

Если суммы не совпали

Несовпадение это не приговор файлу, а сигнал разобраться. Действуйте по списку:

1. не запускайте файл до выяснения: содержимое отличается от опубликованного издателем, и причина пока неизвестна;
2. перекачайте файл, лучше с другого зеркала или прямо с официального сервера, и посчитайте сумму заново: одна моргнувшая сеть объясняет большинство несовпадений на практике;
3. проверьте, тот ли файл сверяете: у релизов с похожими названиями бывают версии и архитектуры, и сумма для образа amd64 не сойдётся с файлом arm64;
4. проверьте, не посчитали ли вы хеш не того объекта: текстового файла со списком сумм вместо образа, страницы загрузки, обёртки-архива. В терминале это выглядит как передача certutil пути к странице, а не к файлу;
5. сверьте алгоритм: сумма SHA-1 рядом с ожидаемой SHA-256 не сойдётся, хотя на вид обе длинные строки из hex-символов;
6. если несовпадение повторилось на официальном источнике, сообщите издателю: на странице могла остаться сумма от предыдущей версии файла.

Типичные ошибки

• сравнивают сумму с чужой строкой из списка: у релиза по десять сумм на разные файлы, и взятая не из той строки сумма не сойдётся при полностью целом файле;
• копируют сумму вместе с лишним пробелом или переносом строки: строковое сравнение честно сообщает о несовпадении, и человек перекачивает исправный файл;
• считают хеш файла с суммами, а не самого образа: SHA256SUMS тоже файл, и у него своя сумма;
• сверяют MD5 из устаревшей инструкции, когда проект уже перешёл на SHA-256, и делают ложный вывод о битой загрузке;
• доверяются сумме с того же зеркала, откуда скачали файл: скомпрометированное зеркало подменяет и файл, и сумму рядом с ним, и сверка проходит без замечаний;
• сравнивают на глаз по первым десяти символам: короткий фрагмент мало о чём говорит, несовпадение может прятаться в конце строки.

Частые вопросы

Подойдёт ли онлайн-калькулятор хешей вместо командной строки?

Для текста и небольших текстовых файлов вполне: генератор SHA-256 и генератор SHA-512 считают всё в браузере и позволяют загрузить файл с диска, если это текст. Гигабайтные образы и бинарные архивы через браузерный инструмент честно не посчитать, для них и существуют certutil и sha256sum. Когда издатель опубликовал сразу несколько сумм, удобно один раз вставить содержимое в мультихеш-инструмент и получить все алгоритмы рядом.

Сумма сошлась, значит файлу можно доверять?

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

Зачем сверять, если сумма лежит рядом с файлом на том же сервере?

Сверка с суммой того же сервера всё равно ловит битые загрузки: обрыв связи, ошибки диска, кривые прокси. От злого умысла владельца сервера это не защищает, и честный ответ такой: для защиты от подмены нужна подпись с публичным ключом издателя либо сумма из независимого канала. Практическое правило: файл берите откуда угодно, сумму только с официальной страницы.

Издатель публикует только MD5. Что делать?

Сверять стоит и MD5: от случайной порчи при загрузке он защищает надёжно, а сконструированные коллизии строятся намеренно и случайную порчу не имитируют. Граница прежняя: целенаправленную подмену MD5 не заметит. Если файл критичный, поищите тот же релиз в источнике с SHA-256 или с подписью: крупные проекты обычно публикуют суммы сразу в нескольких форматах.

Почему у пустого файла тоже есть сумма?

Хеш-функция определена для любых входных данных, включая нулевую длину: SHA-256 пустого файла это e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855, константа, одинаковая во всех системах. Отсюда полезная самопроверка: если команда вдруг выдала эту константу, значит, вы посчитали сумму не того объекта или файл оказался пустым.