5

I'm trying to follow the instructions to verify a downloaded file here:

http://www.pps.univ-paris-diderot.fr/~jch/software/pgp-validating.html

Get a local copy of the signing key

You will need to know the key id of the key you want to confirm. If you are using ASDF-Install, ASDF-Install will complain about an unknown key, and tell you the ID. Otherwise, download both the tarball and the signature file, and pass the signature file to GnuPG:

gpg cl-yacc-0.2.tar.gz.asc
GnuPG will complain about an unknown key, and tell you the ID. At that point, do

gpg --recv id
to download a local copy of the key.

I am trying to verify the downloaded file:

libevent-2.0.22-stable.tar.gz

And I have this signature file:

libevent-2.0.22-stable.tar.gz.asc

Following the steps above, this is what I got:

~/Downloads$ gpg libevent-2.0.22-stable.tar.gz.asc 
gpg: assuming signed data in 'libevent-2.0.22-stable.tar.gz'
gpg: Signature made Mon Jan  5 08:16:20 2015 MST using RSA key ID 8D29319A
gpg: Good signature from "Nick Mathewson <nickm@alum.mit.edu>" [unknown]
gpg:                 aka "Nick Mathewson <nickm@wangafu.net>" [unknown]
gpg:                 aka "Nick Mathewson <nickm@freehaven.net>" [unknown]
gpg:                 aka "[jpeg image of size 3369]" [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: B35B F85B F194 89D0 4E28  C33C 2119 4EBB 1657 33EA
     Subkey fingerprint: EF00 F369 1387 FCC5 8CD6  8E13 9103 97D8 8D29 319A

~/Downloads$ gpg --recv 8D29319A
gpg: requesting key 8D29319A from hkps server hkps.pool.sks-keyservers.net
gpg: key 165733EA: "Nick Mathewson <nickm@alum.mit.edu>" not changed
gpg: Total number processed: 1
gpg:              unchanged: 1

Next, it says:

Confirm the key from an independent source

You now need to confirm the key from an independent source i.e. neither the signature file nor the keyserver.

Find out more about the key

Armed with the ID of the key you are interested in, check the key on on your favourite keyserver interface (choose “verbose index”). You will find all the uids (e-mail addresses) of the person who signed the key, as well as the people who have signed that key.

As far as I can tell, the phrase armed with the ID of the key you are interested in refers to: 8D29319A. In any case, I tried entering every number, fingerprint, and ascii armored public key in that linked keyserver interface, and I just got exception after exception.

What am I doing wrong?

$ gpg --version
gpg (GnuPG/MacGPG2) 2.0.28
libgcrypt 1.6.3
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: ~/.gnupg
Supported algorithms:
Pubkey: RSA, RSA, RSA, ELG, DSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
        CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2
$
7stud
  • 151
  • 1
  • 3
  • I might also be wrong, but doesn't the warning say, that the certificate is self signed? – Sebastian Dec 18 '15 at 10:04
  • The warning basically says "No one you trust has signed this key", you need to check for yourself if you trust this key or not. See [this](http://security.stackexchange.com/questions/6841/ways-to-sign-gpg-public-key-so-it-is-trusted) answer. – BadSkillz Dec 18 '15 at 10:16
  • @BadSkillz: I see that warning--and I may have to deal with that at some point--but does the warning have anything to do with my inquiry? My question was why the key id will not be accepted by the keyserver at the linked keyserver interface? I think the whole point of the tutorial is how to verify files from someone you can't contact. – 7stud Dec 18 '15 at 10:27
  • @Sebastian, See my comment above. – 7stud Dec 18 '15 at 10:27
  • @7stud have a look at [this page](http://pgp.surfnet.nl:11371/pks/lookup?op=vindex&search=Nick+Mathewson&fingerprint=on). These are the keys for Nick Mathewson, you can check the fingerprint here. – BadSkillz Dec 18 '15 at 10:48

2 Answers2

5

You did nothing wrong. The signature is correct, but GnuPG could not verify the key's validity, thus the signature is not deemed valid. With other words, GnuPG explains you that while the signature is issued by a totally valid key, the key could have issued by anybody (you can create keys for arbitrary mail addresses, there is no central instance verifying them, especially key servers do not do!).

Now you have two options:

  • you can try to validate the key through the web of trust (which means finding a "trust path" from keys you already trust to the author's key, and will also remove the "unverified" message) or
  • validate through some other means, for example by comparing the fingerprint or at least long key ID with another, trusted source (short key IDs are insecure, so don't use them for verifying keys). This basically means you have another, trusted source (a basic verification would be through the product's web site listing the key ID/fingerprint, given it is at least received through an encrypted connection using HTTPs) with GnuPG's output of the public key used for signing:

    Primary key fingerprint: B35B F85B F194 89D0 4E28  C33C 2119 4EBB 1657 33EA
    

    (the long key ID equals the last 16 characters 21194EBB165733EA, the short ID is the last 8 characters 165733EA).

Jens Erat
  • 23,816
  • 12
  • 75
  • 96
  • *...you can create keys for arbitrary mail addresses, there is no central instance verifying them, especially key servers do not do!* -- I didn't expect the key server to verify anything, I only expected what the author said: *You will find all the uids (e-mail addresses) of the person who signed the key, as well as the people who have signed that key.* Is that incorrect? Based on what you said, it seems reasonable that all email addresses associated with that public key would be returned by that server.... – 7stud Dec 18 '15 at 11:14
  • If you fetch a key, you also get the certifications (signatures) from others on that key. At the beginning, only their key IDs will be printed. You have to recursively fetch them to verify against them locally, but you can also have a [look at the key server's output](http://pool.sks-keyservers.net/pks/lookup?op=vindex&search=0x21194EBB165733EA&fingerprint=on). – Jens Erat Dec 18 '15 at 11:18
  • 1
    Again, all those mail addresses are generally unverified, and a large number of signatures does generally can also mean an attacker simply created a large number of keys to sign each other, which is easily performed within some minutes using scripts. – Jens Erat Dec 18 '15 at 11:18
0

Simple answer to the real question: use hex notation in the search string.

It looks like you were right in your thinking:

As far as I can tell, the phrase armed with the ID of the key you are interested in refers to: 8D29319A.

You need to search for that ID on the linked site, or another keyserver interface, using 0x8D29319A in the search box. That site doesn't say that, although others do, and the instructions you followed didn't specify that. The site your gpg accessed to retrieve the key has a web-based interface, and it does say to use the hex notation when searching for a key by ID.

BTW: Whenever working with obvious, or even possible, hex values; if one way doesn't work, try prefixing the "0x" to the number and test again.

Your next step is confirming the key from an independent source, as the instructions you followed said. The idea behind getting the info from the linked keyserver is to find the other signers of the questioned certificate, and try to find a path of trust from those you trust to those who trust the new key. Lacking that you can try "out-of-band" contact with a signer of the key to verify it. (Face-to-face, of course, being the best, method. How far you need to go to verify that key is up to your judgement, and the security needs of your situation.

Bright blessings in your endeavors.

  • The last paragraph (above the last sentence) has useful information. But the general answer, i.e. "use hex notation", has absolutely nothing to do with OPs problem. He has no issues whatsoever locating the key or passing the right key ID to gpg. – grochmal Jan 10 '17 at 03:58
  • Re-read his question: "As far as I can tell, the phrase armed with the ID of the key you are interested in refers to: `8D29319A`. In any case, I tried entering every number, fingerprint, and ascii armored public key in that linked keyserver interface, and I just got exception after exception. What am I doing wrong?" –  Jan 10 '17 at 05:51