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 оригіналу допомагає виявляти зміни під час перенесення, якщо порівняти його з копією. Список еталонів теж зберігають так, щоб він не зник і не був перезаписаний разом з оригіналами. Якщо фотопрограма перезаписала орієнтацію чи метадані знімання, хеш може змінитися за майже незмінного зображення. Тому спочатку визначають мету: точне збереження байтів чи змістову відповідність відредагованого фото. Для цілої папки одного файлового хешу замало: потрібні список включених файлів, відносні шляхи та значення кожного.
У спільному рецензуванні документів хеш може закріплювати перевірену редакцію. Але збіг хешу не замінює свідчення, що хтось прочитав увесь текст або звірив переклад. Спершу записують, що, коли й яким методом перевірили, а тоді пов'язують запис зі значенням файлу. Ілюстрація статті — власна пояснювальна схема порівняння байтів, походження еталона та меж перевірки, а не вимірювання чи сертифікат. Послідовно фіксуйте об'єкт і алгоритм, джерело еталона та межі висновків. Це дозволить іншій людині відтворити процедуру без перебільшення значення збігів і розбіжностей.