30

I recently migrated from one installation of Ubuntu to another, and in the process changed my username. I imported my public/private key pair into gpg, and while decryption (using my private key) works fine, whenever I attempt to encrypt something to myself with my public key I get the following warning message:

It is NOT certain that the key belongs to the person named
in the user ID.  If you *really* know what you are doing,
you may answer the next question with yes.

After that it asks me whether I really want to use the key (I always answer "yes", because it is in fact the only key in my keyring and I know where it came from). I can decrypt stuff just fine, so why does gpg throw a hissy fit whenever I try to encrypt something? And how can I prevent this message from appearing again?

3
  • Do any of the answers to this older question at stackoverflow help?: stackoverflow.com/q/9460140/2422988
    – Paul
    Jun 10, 2013 at 15:06
  • @Paul, yes, that link helped a bit. I set the "trust" level of my key to be ultimate, and that seems to have fixed the problem. But what was the problem? Why was this happening, and did I fix it or just alleviate the symptoms?
    – fouric
    Jun 13, 2013 at 1:16
  • Sorry InkBlend, I'm afraid my ability to sift through and compare search results exceeds my knowledge of pgp in this case, hence my non-attempt to claim this as an Answer. It looks like Garrett knows what's going on, though.
    – Paul
    Jun 13, 2013 at 3:30

3 Answers 3

38

I ran into the same issue however I no longer had access to the old key. So you can recreate the trust on your old key with this:

gpg --edit-key [email protected]
gpg> trust
Please decide how far you trust this user to correctly verify other users' keys
(by looking at passports, checking fingerprints from different sources, etc.)

  1 = I don't know or won't say
  2 = I do NOT trust
  3 = I trust marginally
  4 = I trust fully
  5 = I trust ultimately
  m = back to the main menu

Your decision? 5
Do you really want to set this key to ultimate trust? (y/N) y
1
  • OP has done this (noted in the comments), but good to have it stated as an answer.
    – muru
    Sep 12, 2014 at 14:44
19
+50

I managed to reproduce the problem which you are experiencing. I did so doing the following:

$ gpg --no-default-keyring --keyring ./test-keyring  --secret-keyring ./test-secring --trustdb-name ./test-trustdb --no-random-seed-file --gen-key

<specified parameters and let it do its thing>

gpg: key 58018BFE marked as ultimately trusted
public and secret key created and signed.

<snip>

$

Notice that the process marked the key as "ultimately trusted".

Now I export the keys:

$gpg --no-default-keyring --keyring ./test-keyring  --secret-keyring ./test-secring --trustdb-name ./test-trustdb --no-random-seed-file --export-secret-keys -a >private.key

$gpg --no-default-keyring --keyring ./test-keyring  --secret-keyring ./test-secring --trustdb-name ./test-trustdb --no-random-seed-file --export -a > public.key

Now I import to a new gpg database:

$gpg --no-default-keyring --keyring ./test2-keyring  --secret-keyring ./test2-secring --trustdb-name ./test2-trustdb --no-random-seed-file --import public.key

$gpg --no-default-keyring --keyring ./test2-keyring  --secret-keyring ./test2-secring --trustdb-name ./test2-trustdb --no-random-seed-file --import private.key

Now if I attempt to encrypt using the new keyrings I get:

$ gpg --no-default-keyring --keyring ./test2-keyring  --secret-keyring ./test2-secring --trustdb-name ./test2-trustdb --no-random-seed-file -r Fake -e
gpg: AE3034E1: There is no assurance this key belongs to the named user

pub  1024R/AE3034E1 2013-06-13 Fake User <[email protected]>
 Primary key fingerprint: AD4D BAFB 3960 6F9D 47C1  23BE B2E1 67A6 5801 8BFE
      Subkey fingerprint: 58F2 3669 B8BD 1DFC 8B12  096F 5D19 AB91 AE30 34E1

It is NOT certain that the key belongs to the person named
in the user ID.  If you *really* know what you are doing,
you may answer the next question with yes.

The reason for this is the "web of trust" model. By default, in order for a public key to be trusted, it requires either 1 "ultimate" trust certificate (typically where you personally have verified the identities of the people involved), or 3 "marginal" trust certificates (where somebody you know, who knows somebody you know ... has signed the certificate).

Because gpg is a security application, it warns you if you are attempting to encrypt to a key which is not listed as trusted. The reason your own key isn't trusted in this case is simple. It is because you did not export the trust relationships from the previous gpg instance. To do this, use the --export-ownertrust and --import-ownertrust commands.

As always, refer to the man page.

1
  • 1
    The key thing is that all data about key trust is stored separately from the keyring (both secret and public)! ~/.gnupg/trustdb.gpg holds the trust database, pubring.gpg the public keys and secring.gpg the secret keys. Please refer to the GnuPG documention on this.
    – gertvdijk
    Jun 14, 2013 at 14:46
9

You can use the --always-trust flag to skip this message.

4
  • 2
    This is absolutely true, but that's just taking away the symptoms, not the disease. Your solution is like taking an aspirin because you've got cancer...
    – Fabby
    Aug 10, 2015 at 10:04
  • 3
    --always-trust is a good solution in some cases, but if the key in question really is the user's own key, then it should just be given ultimate trust. Dec 13, 2015 at 20:49
  • 4
    My disease is GPG's stubborn insistence on a keyring fucking up my programatic file encryption, and doing so in different ways on every VM I install the software on.
    – bbozo
    Nov 8, 2016 at 10:35
  • @BlacklightShining and if I was not yet able to verify that, Evolution doesn't permit to encrypt mails to that address. No idea why encrypting a text to someone requires absolute trust – and with just marginal trust should not be possible.
    – Izzy
    May 17, 2017 at 18:17

You must log in to answer this question.

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