37

As an example, this project offers an *.asc file with a PGP signature to verify the contents of the download (as opposed to a checksum, you can see the empty column): https://ossec.github.io/downloads.html

How would I use this file? I tried gpg --verify and other variants, but it seems to be matching the name up to the file, however the filename as it is downloaded is not exactly the same... not sure how it is supposed to work.

Improve this question
1

2 Answers 2

Reset to default
37

  1. Download the key file:

    wget https://ossec.github.io/files/OSSEC-ARCHIVE-KEY.asc

  2. Inspect the key file to confirm it has EE1B0E6B2D8387B7 as its keyid.

    gpg --keyid-format long --list-options show-keyring OSSEC-ARCHIVE-KEY.asc

  3. If correct, then import the key:

    gpg --import OSSEC-ARCHIVE-KEY.asc

  4. Download the software package

    wget https://github.com/ossec/ossec-hids/archive/2.9.3.tar.gz

  5. Download the signature file

    https://github.com/ossec/ossec-hids/releases/download/2.9.3/ossec-hids-2.9.3.tar.gz.asc

  6. Verify it

    gpg --verify ossec-hids-2.9.3.tar.gz.asc 2.9.3.tar.gz

    Output

    gpg: Signature made Sat Dec 23 16:13:01 2017 UTC
gpg:                using RSA key EE1B0E6B2D8387B7
gpg: Good signature from "Scott R. Shinn <[email protected]>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: B50F B194 7A0A E311 45D0  5FAD EE1B 0E6B 2D83 87B7
Improve this answer
6
  • 3
    It seems that the --verify option expects the signature file
    – niahoo
    Feb 2, 2019 at 15:17
  • 3
    I get gpg: WARNING: "--show-keyring" is a deprecated option gpg: please use "--list-options show-keyring" instead
    – Dan Dascalescu
    May 13, 2019 at 4:45
  • @DanDascalescu I posted a refined answer that doesn't depend on that deprecated command.
    – aef
    Dec 9, 2020 at 5:18
  • This answer uses potentially spoofable long IDs for verification. Full fingerprints should be used whenever possible to avoid attacks. See my refined answer for explanation.
    – aef
    Dec 9, 2020 at 5:21
  • @Евгений Новиков as @niahoo says, it looks like --verify wants the signature file
    – robertspierre
    Jan 31, 2022 at 17:55
13

This further refines Евгений Новиков's answer. It doesn't use deprecated GnuPG commands and avoids potentially spoofable key IDs for authentication:

Download the files

Acquire the OpenPGP certificate that the author uses to issue signatures:

wget https://ossec.github.io/files/OSSEC-ARCHIVE-KEY.asc

Then acquire the detached signature issued by the author:

wget https://github.com/ossec/ossec-hids/releases/download/2.9.3/ossec-hids-2.9.3.tar.gz.asc

Finally acquire the file that you intend to authenticate:

wget https://github.com/ossec/ossec-hids/archive/2.9.3.tar.gz

Display and thoroughly compare the fingerprint

Before importing the certificate, display the full 40 character long OpenPGP certificate fingerprint and make sure it fully matches the fingerprint of the authors certificate.

Attention: You should acquire the fingerprint through a secure channel from the author. Apart of meeting the author physically to exchange the fingerprint, the next best thing would be a fingerprint displayed on the author's website and accessed via an https: schemed URI. The author did publish one here.

Attention: If the author only displays a short ID (8 characters long, e.g. 2D8387B7) or long ID (16 characters long, e.g. EE1B0E6B2D8387B7) better be sceptical and ask the author to publish the full fingerprint, as both the short ID and the long ID have been demonstrated to be spoofable (read more here)

gpg --import --import-options show-only OSSEC-ARCHIVE-KEY.asc

Older versions of GnuPG didn't display the full fingerprint by default. Try to add the --fingerprint flag if it is not displayed.

The output is supposed to look like this:

pub   rsa4096 2011-03-10 [SC]
      B50FB1947A0AE31145D05FADEE1B0E6B2D8387B7
uid                      Scott R. Shinn <[email protected]>
sub   rsa4096 2011-03-10 [E]

The OpenPGP certificate fingerprint in this case is:

B50FB1947A0AE31145D05FADEE1B0E6B2D8387B7

Sometimes fingerprints are displayed in segments of 4 characters each with whitespace to make it easier for humans to read. In this case it is safe to ignore the whitespace for comparison:

B50F B194 7A0A E311 45D0  5FAD EE1B 0E6B 2D83 87B7

Attention: Be sure not only to compare parts of the fingerprint, as this again opens up room for spoofing attacks.

For easy and thorough comparison just copy both fingerprints equally formatted in subsequent lines in a text editor of your choice and visually match them.

Import the certificate

If the full fingerprint is an exact match, import the certificate into your local GnuPG keyring:

gpg --import OSSEC-ARCHIVE-KEY.asc

Authenticate the file

Now you can cryptographically verify the file exactly matches the one published and signed by the author.

gpg --verify ossec-hids-2.9.3.tar.gz.asc 2.9.3.tar.gz

Attention: Be sure to always list both the detached signature and the file to authenticate here. Apart of detached signatures there are other types of signatures and not realizing this can lead to wrong assumptions of authenticity if only the signature file is listed.

The output is supposed to look like this:

gpg: Signature made Sa 23 Dez 2017 17:13:01 CET
gpg:                using RSA key EE1B0E6B2D8387B7
gpg: Good signature from "Scott R. Shinn <[email protected]>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: B50F B194 7A0A E311 45D0  5FAD EE1B 0E6B 2D83 87B7

Attention: In case the file has been manipulated, you are supposed to see something like this:

gpg: Signature made Sa 23 Dez 2017 17:13:01 CET
gpg:                using RSA key EE1B0E6B2D8387B7
gpg: BAD signature from "Scott R. Shinn <[email protected]>" [unknown]

If this happens you should not use or execute the contents of the file as a precaution and contact the author. If the author cannot be reached, raising awareness publicly is the next best thing.

Authenticating files published by the author time and time again

The warning displayed in the last step is a hint that it would be a good idea to certify the imported author's signing certificate with your own personal OpenPGP certificate after you made sure it is legit.

If you keep and maintain your GnuPG keystore over a long time you don't need to verify the author's certificate for each new file again and make the whole process both easier and less prone to attack in the future.

Attention: A personal OpenPGP certificate is mandatory for this. Instruction for creating one are not the topic of this answer.

Issuing a certification works like this:

gpg --lsign B50FB1947A0AE31145D05FADEE1B0E6B2D8387B7

It tells both GnuPG and yourself in the future that you already thoroughly verified this author's certificate.

Afterwards the output of gpg --verify ossec-hids-2.9.3.tar.gz.asc 2.9.3.tar.gz looks much more clean and assuring like this:

gpg: Signature made Sa 23 Dez 2017 17:13:01 CET
gpg:                using RSA key EE1B0E6B2D8387B7
gpg: Good signature from "Scott R. Shinn <[email protected]>" [full]
Improve this answer
4
  • The link you give provides no evidence at all for spoofing 64-bit, and links to a now-gone Debian blog that Wayback shows only claimed collision for 64-bit and explicitly said collision is NOT sufficient for spoofing. Moreover, PGP signature packets use the 64-bit keyid, so if that WERE broken you couldn't trust any PGP signatures, including key updates, for anything.
    – dave_thompson_085
    Dec 9, 2020 at 9:06
  • @dave_thompson_085 mailarchive.ietf.org/arch/msg/openpgp/… nullprogram.com/blog/2019/07/22 As far as I know, this doesn't compromise the whole system but makes all but the fingerprint unsafe for key identification. If I remember correctly this is because implementations only use the long ID as hint and have to cryptographically verify it by checking signatures anyway.
    – aef
    Dec 9, 2020 at 11:50
  • Collision allows a malicious party to substitute one malicious key for another -- but if you trust any malicious key (even without collision or substitution) you're already in trouble, and this doesn't really make it any worse, just more confusing. Your second link explicitly says: An important detail is that this technique doesn’t target any specific key ID. Cloning someone’s long key ID is still very expensive.
    – dave_thompson_085
    Dec 10, 2020 at 7:28
  • 2
    Finding random collisions is documented since 2013 at least and now we live in the age of ubiquitous cloud computing and stolen AWS accounts with immense computing power even for underfunded bad actors. Sure you can keep using long IDs if you want, but I honestly think this is reason enough to prefer fingerprints instead. At least people should know this and decide what they prefer and this is one reason I gave this refined answer.
    – aef
    Dec 10, 2020 at 14:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .