Загруженный файл имеет неправильный sha1 хеш что делать
Доброго времени суток!
Как часто вы проверяете скачиваемые файлы на равенство хеш-сумм? Я — никогда. Но сегодня я почему-то решил порвать с этой порочной практикой и сделать свою жизнь более безопасной.
Согласитесь, основная причина не сравнивать хеш-сумму файла — это лень. Нужно искать какую-нибудь программу, запускать ее, натравливать на файл, и это просто уйма действий. Как можно упростить эту процедуру? Я не придумал ничего лучше, чем добавить в контекстное меню файла опцию «Посчитать хеш». Интересующимся предлагаю краткую инструкцию.
1. Установка программы
Берем отсюда File Checksum Integrity Verifier utility — консольную утилиту для вычисления и сравнения хешей MD5 и SHA-1 от Microsoft. Там же можно прочитать, что это за зверь и с чем его едят. Скачанный файл Windows-KB841290-x86-ENU.exe можно открыть как zip архив и увидеть, что он содержит два файла: собственно fciv.exe и ReadMe.txt, содержащий справку к утилите. Файл ReadMe нас не интересует, а fciv.exe нужно поместить в одну из директорий, прописанных в переменной PATH, дабы вызывать ее из командной строки без указания полного пути. Я поместил в system32. Проверить, что утилита работает, можно, натравив ее из командной строки на любой файл:
fciv -md5 C:\test.dat — для вычисления MD5
fciv -sha1 C:\test.dat — для вычисления SHA-1
2. Создание элемента контекстного меню
Для расширения контекстного меню файлов нужно будет немного подшаманить в реестре.
Запускаем regedit.exe, идем в HKEY_CLASSES_ROOT\* — это раздел, отвечающий за контекстное меню всех типов файлов. В разделе shell создаем подраздел с любым именем (у меня это fciv_md5). В параметре по умолчанию прописываем желаемое название пункта меню (напрмер, Compute MD5). У созданного подраздела (fciv_md5) создаем еще один подраздел с именем command, и у него в параметре по умолчанию прописываем магическую строчку:
cmd.exe /k fciv -md5 "%1"
Строка предписывает запустить cmd.exe с командой fciv -md5 "%1" и отобразить результат.
Для добавления пункта для вычисления SHA-1 проделываем ту же последовательность действий, меняя лишь названия. Команда в этом случае выглядит так:
cmd.exe /k fciv -sha1 "%1"
Должно получиться что-то вроде этого:
Все вышеперечисленное одним файлом:
3. Вычисляем SHA-1 хеш двумя кликами мыши:
Раз:
Два:
Всем добра и совпадающих хешей!
UPD. Как подсказывает navion в первом комментарии, можно обойтись без установки FCIV и использовать встроенную утилиту CertUtil. В таком случае п.1 становится неактуальным, а команда в regedit меняется на:
для MD5: cmd.exe /k CertUtil -hashfile "%1" MD5
для SHA1: cmd.exe /k CertUtil -hashfile "%1" SHA1,
и, кроме того, появляется возможность вычислять SHA256 хеш: cmd.exe /k CertUtil -hashfile "%1" SHA256
купил обновление на навигатор,а при обновлении через Navitel Navigator update center пишет что загруженный файл имеет не правильный SHA 1 хеш,что делать?
Подскажите, навигатор PN-945 . На него карты на 2017 год можно обновить? Бесплатно или нет? В центре обновления он не видит новые карты
Навигатор с картами 16г не видет платной дороги окружной Воронежа. Устройство на win ce6.0 а обновления 17г установить не получается пишет актувльная версия.
Здравствуйте, у мужа случилась неприятность, помогите пожалуйста разобраться!
"У меня проблема с активацией карт после обновления Навител навигатора.
У меня на ноутбуке стоит центр обновления Навител Навигатор для
поддержания навигатора в автомобиле в актуальном состоянии. У меня в
авто Мультимедийный цент DVM-6408 для штатной установки в автомобиль
Peugeot.
Недавно цент обновления Навител навигатор обновился до версии 2.2.0.32.
После чего предложил обновить сам навигатор до версии 9.6.2598 и карты
до Q1 2016. Я дал добро. После чего флеш карту с обновлением поместил в
свою штатную установку DVM-6408. Перегрузил систему и все пошло. Система
запустилась, прошла этап настройки GPS и зависла на активации
установленных карт. И все, дальше ничего сделать не могу. У меня есть
регистрация на вашем сайте, я от туда скачивал ключ активации и т.д. Да,
флеш карту не менял. Осталась прежняя, на которой предыдущие карты
работали.
Форумы смотрел, пробовал. Ничего не получается.
Надеюсь у вас найдется время ответить мне по моей проблеме. Заранее
благодарен, Дмитрий."
на время загрузки отключите антивирус и встроенный firewall. сделал, без изменений, осталось файл имеет не правильный SHA 1 хеш хочется навигатор об стенку расфигачить
программа не видит карты которые с сайта, программа 9.8.187 ну а карты 9.7 и выше, землю видит а Россию нет. что делать?
Я планирую использовать реализацию AVR-Crypto SHA-1 для HMAC. Однако я не могу сгенерировать правильную сумму SHA-1.
Например, если я вызову функцию со следующим
Я получаю 000000000000000000002C002312290000000029 , а не ожидалось c1bb92851109fe950a2655fa1d4ba1d04719f6fb . Кто-нибудь знает, что может быть не так? Вот реализация AVR-Crypto
ОБНОВЛЕНИЕ Если я инициализирую sha1sum с unsigned char sha1sum[20] = 0; помощью , результирующая сумма будет равна 0x00.
Это? Я использую этот сайт для создания (эталонного) хэша. Я вхожу FFFFFFFFFF , и он дает мне c1bb92851109fe950a2655fa1d4ba1d04719f6fb . Это не правильный хэш?
В коде вопроса есть по крайней мере две ошибки (подробно описанные ниже), но ни одна из них не может объяснить показанный результат и добавленный факт, что unsigned char sha1sum[20] = в вызывающем коде результат изменяется. Что-то не так с переводом исходного кода C, который мы читаем, в машинный код! Скорее всего, sha1_ctx2hash не туда написал, куда надо.
Проблема может быть в заголовке, а не в вопросе, ошибка компилятора. Поскольку мы работаем на 8051, это может быть/было проблемой с типами указателей , особенно в приведениях указателя, которые ДОЛЖНЫ быть указателем одного и того же размер.
Обновление: мы обнаружили еще одну критическую проблему (помимо вероятного небезопасного приведения указателей и двух ошибок, обсуждаемых ниже). В какой-то момент поиска, заменив код одной процедурой, не имеющей зависимости от порядка следования байтов или приведения указателя, вывод стал 0000eb1700007f3d000004f0000059290000fc21 таким, что предполагаемые 32-битные значения усекаются до 16-битных. Действительно, ОП показал:
I have this in my stdint.h : typedef unsigned uint32_t;
Это правильно только для компиляторов, где unsigned int ровно 32-бит , когда единственная гарантия, предоставляемая стандартом C, заключается в том, что он по крайней мере 16-бит , и этот минимум используется большинством компиляторов C для менее чем 32-битных процессоров. (из соображений эффективности; у некоторых даже есть возможность отключить преобразование байтовых операндов в целое число, и они даже довольны 80+80+96 этим 0 ).
Ошибка в тестовом коде: sha1( sha1sum, msg, strlen(msg)) должно быть sha1( sha1sum, msg, strlen(msg)*8) или подобное, потому что параметры длины в битах.
Баг в sha1_lastBlock заголовочном файле wrt: чтение кода
предполагает, что state->length это 8 байт, когда это не так, потому что uint64_t length было изменено на uint8_t length в заголовке (обычно это uint64_t недоступно для компиляторов 8051). Код для случая с обратным порядком байтов (в настоящее время не скомпилированный) также затронут.
Если действительно uint8_t length и, таким образом, допустимо ограничение на длину не более 31 байта, то случаи с прямым порядком байтов и прямым порядком байтов сводятся к lb[SHA1_BLOCK_BYTES-1] = state->length; (без цикла).
Или, для любого беззнакового типа и порядка байтов length :
Примечание. Код *((uint64_t*)&(lb[56])) = state->length записывает 8 байтов length в конец массива lb[] , но корректен только на машинах с обратным порядком байтов и правильным uint64_t .
Исходный код может быть правильным (за исключением приведенной выше потенциальной дополнительной проблемы), но он излишне сложен, учитывая, что целью является хеширование данных в памяти с помощью одного вызова (что sha1 делает), и он не является ни компактным, ни удобочитаемым. Среди прочих вопросов:
Если вам нужна скорость, код, с которого вы начинаете, неадекватен, и ничто не будет полностью соответствовать языку ассемблера. Как и два десятилетия назад, я написал SHA-1 для какой-то цепочки инструментов 8051, и настройка сборки дала огромную экономию по сравнению только с C (IIRC: в основном потому, что 32-битные вращения были бездонными с точки зрения производительности).
Сложность атак на SHA-1. Стоимость указана из расчёта стоимости аренды одного GTX 1060 в 35 долларов/месяц
Намного позже всех остальных, но разработчики библиотек для SSH приняли решение наконец-то отключить по умолчанию устаревшую криптофункцию SHA-1. Сегодня подбор серверного ключа аутентификации SHA-1, то есть коллизия с выбранным префиксом, на арендованном кластере GPU обойдётся в $45 тыс., как указано в таблице вверху. Это делает атаку доступной не только для государственных спецслужб, но и для коммерческих клиентов.
Об отключении SHA-1 по умолчанию одновременно объявили разработчики опенсорсных библиотек OpenSSH (release notes) и libssh (изменение кода).
Алгоритм SHA (Secure Hash Algorithm) разработан АНБ совместно с NIST. Первую версию SHA-0 представили в 1993 году, но вскоре АНБ отозвало данную версию, сославшись на обнаруженную ими ошибку, которая так и не была раскрыта.
Исправленную версию АНБ опубликовала в 1995 году, она получила название SHA-1.
Понятно, что область значений дайджеста меньше области входных значений. Но на практике дайджест-коллизии должны быть неосуществимы, учитывая возможности производительности имеющихся вычислительных ресурсов. К сожалению, SHA-1 уже не соответствует этому критерию.
В 2017 году сотрудники компании Google и Центра математики и информатики в Амстердаме представили первый способ генерации коллизий для SHA-1.
Они опубликовали и доказательство: два документа PDF с разным содержимым, но одинаковыми цифровыми подписями SHA-1.
На сайте shattered.it можно проверить любой файл на предмет того, входит ли он в пространство возможных коллизий. То есть можно ли подобрать другой набор данных (файл) с таким же хешем. Вектор атаки здесь понятен: злоумышленник может подменить «хороший» файл своим экземпляром с закладкой, вредоносным макросом или загрузчиком трояна. И этот «плохой» файл будет иметь такой же хеш или цифровую подпись.
В последние годы множество программ и сервисов перестали использовать SHA-1 после того, как исследователи продемонстрировали практические способы подделки цифровых подписей, использующих SHA-1. Единодушное мнение экспертов состоит в том, что этот алгоритм теперь не безопасен почти во всех контекстах безопасности.
Компания Google давно выразила своё недоверие SHA-1, особенно в качестве использования этой функции для подписи сертификатов TLS. Ещё в 2014 году группа разработчиков Chrome объявила о постепенном отказе от использования SHA-1.
В 2017 году исследователи использовали инфраструктуру Google, чтобы произвести вычисления и проверить теоретические выкладки, сколько займёт поиск коллизии. Разработчики говорят, что это было одно из самых крупных вычислений, которые когда-либо проводила компания Google. В общей сложности было произведено девять квинтиллионов вычислений SHA-1 (9 223 372 036 854 775 808), что потребовало 6500 процессорных лет на первой фазе и 110 лет GPU на второй фазе атаки.
В 2019 году исследователи Гаэтан Лоран и Томас Пейрин продемонстрировали атаку на отыскание коллизии с выбранным префиксом (chosen-prefix), которая имеет практический смысл для подбора конкретных ключей шифрования PGP/GnuPG. Наконец, в январе 2020 года авторам удалось на порядок оптимизировать атаку и снизить её теоретическую стоимость до коммерчески приемлемой цены (см. таблицу выше и pdf). Для демонстрации они создали пару разных ключей PGP/GnuPG с одинаковыми сертификатами SHA-1.
В качестве защиты от атаки на отыскание коллизий SHA-1 рекомендуется перейти на более качественные криптографические хеш-функции SHA-256 и SHA-3.
На это исследование от января 2020 года ссылаются разработчики OpenSSH, которые написали в примечаниях к последнему релизу: «Теперь можно выполнять атаки с выбранным префиксом по алгоритму SHA-1 менее чем за 50 тысяч долларов США. По этой причине в ближайшем будущем мы будем отключать алгоритм подписи открытого ключа "ssh-rsa" по умолчанию. К сожалению, этот алгоритм всё еще широко используется. Несмотря на существование лучших альтернатив, он долгое время оставался единственным алгоритмом подписи открытого ключа, заданным оригинальными SSH RFC».
В числе лучших альтернатив разработчики OpenSSH называют алгоритмы RFC8332 RSA SHA-2 (поддерживается с версии OpenSSH 7.2 и уже используется по умолчанию, если сервер и клиент его поддерживают), ssh-ed25519 (поддерживается с версии 6.5) и RFC5656 ECDSA (с версии 5.7).
Для проверки, что сервер при генерации открытого ключа для аутентификации использует слабый алгоритм SHA-1, попробуйте подключиться к нему после удаления алгоритма ssh-rsa из списка разрешённых в ssh(1):
Если верификация не проходит и другие типа ключей недоступны, то серверное программное обеспечение следует обновить.
В будущих версиях OpenSSH по умолчанию будет включена опция UpdateHostKeys, при которой клиент будет автоматически переходить на лучшие алгоритмы. Её можно активировать вручную.
Судя по всему, полное отключение SHA-1 займёт немало времени. Гаэтан Лоран из Национального института исследований в информатике и автоматике (Франция), один из соавторов январского исследования, не ожидает, что разработчики OpenSSH быстро это сделают: «Когда они полностью отключат SHA-1, будет невозможно подключиться с новой версии OpenSSH к устройству со старым SSH-сервером, — пишет он. — Вероятно, перед этим они предпримут ряд постепенных шагов (с громкими предупреждениями). С другой стороны, во встроенных системах с SSH, которые не обновлялись в течение многих лет, вероятно, много проблем с безопасностью, так что, возможно, не так уж плохо будет нарушить их работу… Во всяком случае, я вполне доволен этим ходом, это именно то, чего мы хотели добиться :-)».
Линус Торвальдс сказал, что в репозиториях Git коллизии хеша не представляют угрозы безопасности. Он пояснил, что сть большая разница между использованием криптографического хеша для цифровых подписей в системах шифрования и для генерации «идентификации контента» в системе вроде Git. Когда все данные лежат в открытом доступе, то реальная атака практически невозможна. Авторы научной работы приводят пример атаки на документы с идентичным префиксом. Эта атака успешна, потому что сам префикс «закрыт» внутри документа, как блоб. Если же у нас открытые исходники в репозитории, то это совсем другое дело. Вряд ли можно сделать такой префикс из исходного кода (только из блоба). Другими словами, для создания идентичного префикса и последующей генерации веток кода с одинаковыми хешами SHA-1 придётся внедрить в код некие случайные данные, что сразу же будет замечено. Линус говорит, что есть места, куда можно спрятать данные, но git fsck уже вылавливает такие фокусы. Тем не менее, у Линуса есть план, как уйти от использования SHA-1, чтобы никому даже не пришлось конвертировать свои репозитории.
Иногда Вы можете встретить упоминание MD5, SHA-1 или SHA-256 хешей, отображаемых вместе с вашими, но, на самом деле, не знаете, что они означают. Эти, казалось бы, случайные строки текста позволяют Вам проверить, что файлы, которые вы загрузили, не были повреждены или подделаны.
Сравнение хеша в любой операционной системе
Имея это в виду, давайте посмотрим, как проверить хеш файла, который вы загрузили, и сравнить его с тем, который должен быть. Вот методы для Windows, macOS и Linux. Хеши всегда будут идентичны, если вы используете одну и ту же функцию хеширования в одном файле. Не имеет значения, какую операционную систему Вы используете.
Хэш файла в Linux
В Linux обратитесь к терминалу и выполните одну из следующих команд для просмотра хеша файла, в зависимости от типа хеша, который вы хотите посмотреть:
Хэши с криптографической подписью
Вот почему современные дистрибутивы Linux часто предоставляют больше, чем хеши, перечисленные на веб-страницах. Они криптографически подписывают эти хеши, чтобы помочь защититься от злоумышленников, которые могут попытаться изменить хеши. Вы можете проверить криптографическую подпись, чтобы убедиться, что хеш действительно относится к дистрибутиву Linux. Проверка криптографической подписи хеша – более сложный процесс, выходящий за рамки представленной статьи.
Хэш файла в Windows
Этот процесс возможен без какого-либо стороннего программного обеспечения на Windows, благодаря PowerShell.
Чтобы начать работу, откройте окно PowerShell, запустив ярлык Windows PowerShell из меню Пуск .
Выполните следующую команду, заменив "C:\path\to\file.iso" путём к любому файлу, для которого вы хотите просмотреть хеш:
Для создания хеша файла потребуется некоторое время, в зависимости от размера файла, используемого алгоритма и скорости диска, на котором находится файл.
По умолчанию команда покажет хеш SHA-256 для файла. Однако, можно указать алгоритм хеширования, который необходимо использовать, если вам нужен хэш MD5, SHA-1 или другой тип.
Выполните одну из следующих команд, чтобы задать другой алгоритм хэширования:
Get-FileHash C:\path\to\file.iso -Algorithm MD5
Get-FileHash C:\path\to\file.iso -Algorithm SHA1
Get-FileHash C:\path\to\file.iso -Algorithm SHA256
Get-FileHash C:\path\to\file.iso -Algorithm SHA384
Get-FileHash C:\path\to\file.iso -Algorithm SHA512
Get-FileHash C:\path\to\file.iso -Algorithm MACTripleDES
Get-FileHash C:\path\to\file.iso -Algorithm RIPEMD160
Сравните результат хеш-функций с ожидаемым результатом. Если это то же значение, файл не был поврежден, подделан или иным образом изменен от исходного.
Как используют хеши для проверки данных
Хэши являются результатом работы криптографических алгоритмов, и представляют собой строку символов. Часто эти строки имеют фиксированную длину, независимо от размера входных данных.
Взгляните на диаграмму, и вы увидите, что хеш «Fox» и «The red fox jumps over the blue dog» имеет одинаковую длину. Теперь сравните второй пример на графике с третьим, четвертым и пятым. Вы увидите, что, несмотря на незначительные изменения во входных данных, хеши сильно отличаются друг от друга. Даже если кто-то изменит очень маленький фрагмент входных данных, хэш будет резко меняться.
MD5, SHA-1 и SHA-256 – это разные алгоритмы хеш-функции. Создатели программного обеспечения часто указывают хеш для загружаемых файлов.
Таким образом, Вы можете загрузить файл, а затем сравнить опубликованный с рассчитанным для загруженного файла, чтобы подтвердить, что Вы получили оригинальный файл, и что он не был поврежден во время процесса загрузки или подделан злонамеренно.
Как мы видели выше, даже небольшое изменение в файле резко изменит хэш.
Они также могут быть полезны, если файл получен из неофициального источника, и вы хотите проверить, что это «законно». Допустим, у Вас есть Linux.iso-файл, который вы откуда-то получили, и вы хотите убедиться, что он оригинальный. Вы можете посмотреть хеш этого ISO-файла в интернете на веб-сайте дистрибутивов Linux. Затем рассчитать хеш-функцию на вашем компьютере и убедиться, что результат соответствует хеш-значению, которое вы ожидаете от него. Это подтверждает, что у вас тот же файл, который предлагается для загрузки на официальном веб-сайте дистрибутива Linux.
Хэш файла на macOS
macOS содержит команды для просмотра различных типов хэшей. Для доступа к ним запустите окно терминала. Вы найдете его в Finder → Приложения → Утилиты → Терминал.
Команда md5 показывает MD5-хеш файла:
Команда shasum показывает хеша SHA-1 по умолчанию. Это означает, что следующие команды идентичны:
shasum -a 1 /path/to/file
Чтобы отобразить хеш файла SHA-256, выполните следующую команду:
shasum -a 256 /path/to/file
Читайте также: