Коли ви завантажуєте великий файл — образ операційної системи, архів дистрибутива — поруч часто публікують рядок на кшталт SHA-256 контрольної суми. Порівняння цього рядка з хешем завантаженого файлу дозволяє переконатися, що файл не пошкодився під час передачі.
Як контрольна сума виявляє пошкодження
Через лавинний ефект хеш-функцій навіть один пошкоджений байт при передачі повністю змінить обчислений хеш файлу. Тому будь-яке розходження між очікуваною і обчисленою контрольною сумою однозначно означає, що файл відрізняється від оригіналу — байт у байт.
Чого контрольна сума не гарантує
Збіг хешів підтверджує лише те, що файл ідентичний тому, з якого був обчислений опублікований хеш, — але не те, що цей оригінал безпечний або справді походить від заявленого джерела. Якщо зловмисник підмінить і файл, і опубліковану контрольну суму одночасно (наприклад, на скомпрометованому сайті), перевірка нічого не виявить.
Контрольна сума проти цифрового підпису
На відміну від контрольної суми, цифровий підпис створюється приватним ключем і може бути перевірений лише відповідним публічним ключем — це підтверджує не лише цілісність, а й автентичність джерела. Для критично важливих завантажень (оновлення ПЗ, релізи) поряд із контрольною сумою часто публікують і підпис.
Навіщо це потрібно
- Переконатися, що завантажений архів чи образ ОС не пошкодився при скачуванні.
- Швидко порівняти два великі файли без побайтового зіставлення.
- Перевірити, що резервна копія файлу ідентична оригіналу.
Чому іноді використовують CRC32 замість SHA-256
CRC32 набагато швидший за криптографічні хеш-функції, але його легко підробити навмисно — це не проблема для виявлення випадкового пошкодження при передачі (для чого CRC32 і створювали), але непридатний захист від зловмисника, який хоче підмінити файл непомітно. Тому CRC32 досі трапляється в архіваторах і мережевих протоколах для контролю помилок, а не там, де потрібна саме безпека.