Как проверить загруженный файл с файлом .sig?

Когда я загружаю GCC, у него также есть файл .sig , и я думаю, что он предоставляется для проверки загруженного файла. (Я скачал GCC отсюда).

Но я не могу понять, как мне его использовать. Я пробовал gpg , но он жалуется на открытый ключ.

  [root @ localhost src] # gpg --verify gcc-4.7.2  .tar.gz.sig gcc-4.7.2.tar.gzgpg: Подпись сделана 20 сентября 2012 г., 19:30:44 KST с использованием идентификатора ключа DSA C3C45C06gpg: невозможно проверить подпись: нет открытого ключа [root @ localhost src]  #  

Как проверить загруженный файл с помощью файла .sig ?


Вам необходимо импортировать открытый ключ: C3C45C06

Это можно сделать в три этапа.

  1. найти идентификатор открытого ключа:

    $ gpg gcc-4.7.2.tar.gz.siggpg: Подпись сделана Čt 20. září 2012 , 12:30:44 CEST с использованием идентификатора ключа DSA C3C45C06gpg: Невозможно проверить подпись: нет открытого ключа

  2. импортировать открытый ключ с сервера ключей. Обычно не требуется выбирать сервер ключей, но это можно сделать с помощью - keyserver . Примеры серверов ключей.

    $ gpg —recv-key C3C45C06gpg: запрос ключа C3C45C06 с сервера hkp keys.gnupg.netgpg: ключ C3C45C06: открытый ключ «Jakub Jelinek jakub@redhat.com» importgpg: no окончательно доверенные ключи найденыgpg: Общее количество обработанных: 1gpg: импортированных: 1

Если ошибка команды не выполняется с тайм-аутом, возможно, вы находитесь за брандмауэром, который блокирует порт gpg по умолчанию. Попробуйте использовать параметр —keyserver с портом 80 (почти все брандмауэры разрешают просмотр веб-страниц через порт 80 b/c):

  $ gpg --keyserver hkp:// $ {HOSTNAME}: 80 --recv-keys $ {KEY_ID}  
  1. проверить подпись:

    $ gpg gcc-4.7.2.tar.gz.siggpg: Подпись сделана Čt 20. září 2012, 12:30:44 CEST с использованием идентификатора ключа DSA C3C45C06gpg: Хорошая подпись от «Jakub Jelinek jakub@redhat.com» [неизвестно] gpg : ВНИМАНИЕ: Этот ключ не сертифицирован доверенной подписью! Gpg: Нет никаких указаний на то, что подпись принадлежит владельцу. Отпечаток первичного ключа: 33C2 35A3 4C46 AA3F FB29 3709 A328 C3A2 C3C4 5C06

В выводе должно быть указано «Хорошая подпись».


gpg: ВНИМАНИЕ: этот ключ не сертифицирован с помощью доверенной подписи!

Для другого вопроса;)

6


Этот другой путь особенно важен очень полезно для проверки проектов GNU (например, Octave), поскольку ключ, запрошенный их подписью, может не быть найден ни на одном сервере ключей.

Из http://ftp.gnu.org/README

Существуют также файлы .sig, которые содержат отдельные подписи GPG для вышеуказанных файлов, автоматически подписанные тем же сценарием, который их генерирует.

Вы можете проверить подписи для файлы проекта gnu с файлом связки ключей из:

https://ftp.gnu. org/gnu/gnu-keyring.gpg

В каталоге с файлом связки ключей, исходным файлом для проверки и файлом подписи используется следующая команда :

$ gpg --verify --keyring ./gnu-keyring.gpg foo.tar.xz.sig

4


Вы должны искать на открытых серверах ключей указанный идентификатор ключа: в вашем случае ID C3C45C06 Импортируйте найденный ключ в локальное хранилище ключей, и после этого проверка должна быть в порядке. Я использую Ubuntu 12.04, и он поставляется с программным обеспечением для управления ключами Seahorse. Перед импортом ключей я видел следующее:

  ~/Downloads $ gpg --verify --keyring ./gnu-keyring.gpg icecat-31.5.0.en-US  .linux-x86_64.tar.bz2.sig icecat-31.5.0.en-US.linux-x86_64.tar.bz2gpg: Подпись сделана 9.03.2015 (пн) 22,35,52 EET с использованием идентификатора ключа RSA D7E04784gpg: Может '  t проверить подпись: открытый ключ не найден  

После импорта ключа я увидел следующее:

  ~/Downloads $ gpg -  -verify --keyring ./gnu-keyring.gpg icecat-31.5.0.en-US.linux-x86_64.tar.bz2.sig icecat-31.5.0.en-US.linux-x86_64.tar.bz2gpg: Подпись  сделано 9.03.2015 (пн) 22,35,52 EET с использованием идентификатора ключа RSA D7E04784gpg: Хорошая подпись от «Рубена Родригеса (ключ выпуска GNU IceCat) » gpg: ВНИМАНИЕ: Этот ключ не сертифицирован с  доверенная подпись! gpg: нет никаких указаний на то, что подпись принадлежит владельцу. Отпечаток первичного ключа: A573 69A8 BABC 2542 B5A0 368C 3C76 EED7 D7E0 4784  

v> 1


в соответствии с этим http://gcc. gnu.org/mirrors.html, который должен быть Jakub Jelinek и действителен. я не знаю, где бы вы могли взять его открытый ключ.



В чем разница между «sig» файлы и файлы контрольной суммы, например, на странице загрузки PuTTY?

Речь идет о функциональных различиях между файлами sig и файлами контрольной суммы и о том, как они могут использоваться пользователем, загружающим некоторое программное обеспечение.

Например, на странице загрузки PuTTY для скомпилированных двоичных файлов Windows доступны как файлы sig, так и файлы контрольной суммы, как показано ниже.

В чем функциональная разница между этими типами файлов? Кроме того, хотя я знаю, как проверять контрольные суммы загруженных файлов, как можно использовать файлы sig (в Windows)?


Каков функционал разница между этими типами файлов?

  • Контрольные суммы обеспечивают целостность данных.
  • Цифровые подписи дополнительно обеспечивают аутентичность данных.

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

Злоумышленник может разместить вредоносную версию PuTTY на своем веб-сайте и сделать ее доступной для загрузки. Проверка контрольной суммы в этом случае бесполезна: единственный способ убедиться, что вы не загрузили вредоносную версию PuTYY, — это проверить ее подпись (и).

Кроме того, хотя я знаю, как проверять контрольные суммы загруженных файлов, как можно использовать файлы sig (в Windows)?

Это больше вопрос суперпользователя. У вас есть тот же вопрос, что и у вас.


Контрольные суммы подтверждают простые проверки четности; они в основном могут сказать вам, что два бита где-то перевернулись, и файл поврежден. Они не обеспечивают никакой криптографической безопасности , потому что алгоритмы предназначены только для обнаружения случайных изменений в файле.

сигнатуры , однако, основаны на PGP (Pretty Good Privacy). Алгоритмы работают на довольно стандартной криптографической идее: есть два ключа, закрытый ключ и открытый ключ. Вы можете определить, что закрытый ключ является допустимым, учитывая входной файл и открытый ключ, но у вас нет способа определить, что это был за закрытый ключ. Таким образом мы можем доказать подлинность. Однако этого недостаточно, потому что вы заметите, что открытые ключи и подписи находятся на одном сайте. PGP решает эту проблему, устанавливая доверие , для чего люди из других мест, которые им доверяют, подписывают исходный ключ своими ключами.

Это означает, что если вы используете PGP для проверки подлинности PuTTY, к чему относятся многие люди, серьезно относящиеся к безопасности, хакер не может подделать исполняемый файл, которому можно было бы доверять, без (а) кражи закрытого ключа, который не хранится на этом сервере, или (б) взлом сервера, замена файлов, контрольных сумм, подписей и ключей, а затем кража значительного количества закрытых ключей для установления доверия для этого одного закрытого ключа. Любой сценарий в принципе невозможен (или, по крайней мере, крайне неправдоподобен); даже если единственный закрытый ключ был украден, авторы могли просто отозвать его, что разрушило бы всю цепочку доверия и т. д., которую они затем могли бы без особых проблем настроить снова.

RSA просто использует слишком большие числа, чтобы их можно было вычислить за любой разумный промежуток времени; текущие оценки показывают, что во вселенной недостаточно энтрофии, чтобы реконструировать закрытый ключ, поэтому, если он не украден, он довольно безопасен. В сочетании со способностью устанавливать доверительные отношения это способ добиться очень высокой уверенности в том, что файлы не были злонамеренно изменены.

Вы должны иметь возможность проверять подписи с помощью чего-то вроде Gpg4win, что позволяет вам проверять подписи с помощью ключей, найденных на сайте PuTTY. Также см. Как проверить подписи контрольной суммы PGP RSA и/или DSA для PuTTY?

Оцените статью
clickpad.ru
Добавить комментарий