Программы для вычисления и проверки контрольных сумм - [26] :: Программы

Nikolka00, картина чуть сложнее.

GitHub это площадка Microsoft, где предлагают работать над кодом сообща. Изменения вносят и отслеживают с помощью программы Git (т.н. системы контроля версий, придуманной зачинателем Linux Линусом Торвальдсом). Каждое изменение получает уникальное имя, для чего Git с 2005 и поныне использует хэш SHA1 (хотя летом 2018 задумались о переходе на SHA256). Так решают задачи именования и ссылок «под капотом» GitHub, а сопровождать ли итоги разработки хэшем (и каким именно), — решает разработчик.

Разработчик собирает код проекта в рабочую версию, даёт ей порядковый номер и выкладывает в разделе Releases. Иногда релиз сопровождают хэш и/или цифровая подпись, которые вычисляются с помощью программ типа HashCheck/RHash/GPG/Minisign. Хэш призван гарантировать целостность релиза (дабы мы убедились, что скачанная копия точь-в-точь повторяет оригинал на сервере), а подпись призвана гарантировать подлинность релиза (дабы мы убедились, что оригинал выложил разработчик, а не посторонний). По уму достаточно публиковать подпись (внутри которой есть и хэш), но т.к. проверка подписи требует больше телодвижений, то ограничиваются хэшем, да и тот ленятся проверить. Публиковать же хэш (о чём многие забывают!) уместнее отдельно от файла (т.е. за пределами GitHub), дабы посторонний, получив доступ к аккаунту/серверу и подменив файл, не смог подменить хэш.

Упрощённо расскажем о связи хэшей и файлов. Хэш-алгоритмы делятся на обычные и криптографические. Первые быстрее и прежде всего подмечают неумышленные изменения (скажем, повреждения при копировании файла с обрывами связи или с битого диска). Вторые медленнее и ориентированы на снижение вероятности умышленных изменений (скажем, посторонний воздержится заражать файл вирусом или менять дозу мескалина в протоколе, не имея возможности подогнать хэш своей копии под хэш оригинала).

При выборе хэша (как и других элементов безопасности) следует руководствоваться анализом угроз, а не потребительским угаром «BMW 7 лучше 6, ибо на цифру больше», переменчивой модой «10 000 леммингов не могут ошибаться» или идолопоклонством «это использует NIST, ФСТЭК, Сноуден, компания из списка Fortune 500». Так, для проверки целостности фильмов достаточно обычного хэша CRC32 (либо CRC32C), хотя давно пора внедрить xxHash или SeaHash, подобно тому, как Google внедрила HighwayHash для внутренних нужд, а в недрах Facebook внедрили алгоритм сжатия ZStandard, который способен удивить любителей 7Z и RAR.

Почему же в разделе Releases на GitHub вы часто (а я, кстати, не часто) встречаете хэш SHA512? Расхожее объяснение звучит так: на 64-битных процессорах SHA512 работает в ~1,5 раза быстрее, чем текущий «американский стандарт» SHA256, а запас прочности вселяет дополнительную уверенность. На деле эта прочность если и пригодится, то не раньше эры массовых квантовых вычислений, а до тех пор важным критерием остаётся длина хэша — чем короче хэш, тем меньше весит, быстрее передаётся и удобнее сверять на глаз. Существуют ли прочные хэши короче, чем SHA512, но столь же (или более) быстрые? Да! Например, усечённые SHA512 (т.н. SHA512/256, SHA512/224), Blake2b либо Skein (финалисты конкурса на звание SHA3, забракованные «по идеологическим мотивам»).

Модерирует : gyra, Maz
Версия для печати • Подписаться • Добавить в закладки
Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30