Exporting public key from GnuPG fails with "WARNING: nothing exported"
Asked Answered
K

3

13

Im new to PGP and I'm trying to generate a PGP private key using GnuPG through this tutorial.

Basically, I have type the following command in command prompt (in administrator mode):

  1. gpg --gen-key
  2. Entered all the commands as below: enter image description here

  3. Then I entered the command:

    gpg --armor --output pubkey.txt --export 'Encryption purpose'
    

but get a

WARNING: nothing exported

message.

Can someone tell me what I'm doing wrong?

Also, I will be using PGP to encrypt a webapp download file. I'm planning to create a web application that will generate a file with random numbers that would need be encrypted (in PGP). Then to decrypt, I'm planning to create a stand alone application that will decrypt the file using the private key. So my question is:

  1. Is it possible to extract the private key from the original computer in which the private key was generated to be used with other computers so that other computers could also use the standalone application to decrypt the file using the private key from the original computer?

  2. If this is not possible, how do I share the private key for all computers with the decrypting standalone application (because as I understand, standalone application needs 'a' private key to decrypt the file)? Should I use multiple private keys? How to implement?

Kurzawa answered 9/9, 2015 at 9:9 Comment(0)
V
17

This error is caused by the --export parameter not matching any of the user ids (usually email addresses) listed in gpg --list-keys.

The solution is to run:

  1. gpg --gen-key

Make a note of the email you use to generate the key (eg [email protected]). Then plug that into gpg:

  1. gpg --armor --output mypublic.key --export '[email protected]'

Also in Ubuntu it seems gpg2 is now preferred, so use eg gpg2 --gen-key.

Vernettaverneuil answered 13/1, 2017 at 1:54 Comment(0)
T
8

use this command to see the id:

gpg --list-secret-keys --keyid-format LONG "your_email"

the output will look like that:

sec   rsa4096/30F2B65B9246B6CA 2017-08-18 [SC]
      D5E4F29F3275DC0CDA8FFC8730F2B65B9246B6CA
uid                   [ultimate] Mr. Robot <your_email>
ssb   rsa4096/B7ABC0813E4028C0 2017-08-18 [E]

then enter the command:

gpg --armor --export-secret-keys 30F2B65B9246B6CA

and then you get the key :)

Thier answered 31/1, 2022 at 8:35 Comment(0)
S
4

You've got the --export command wrong. It does not take an export purpose as parameter, but a key or user ID. From man gpg:

--export
    Either export all keys from all keyrings (default keyrings and  those  regis‐
    tered  via  option --keyring), or if at least one name is given, those of the
    given name. The exported keys are written to STDOUT or to the file given with
    option --output.  Use together with --armor to mail those keys.

To export the private key, run --export-secret-keys instead. Public keys cannot be used to decrypt files, only for encryption and verification of signatures.

Strudel answered 9/9, 2015 at 11:25 Comment(8)
how do I find the user id?Kurzawa
In this case, the mail address will be fine. These are very basic concepts of OpenPGP, I'd recommend to read through some information on OpenPGP and GnuPG before delving deeper into the materia.Strudel
@Kurzawa Probably even better – because it's more precise – is to use the short or long key ID shown in the output of gpg --list-keys. One reason is that you might (reasonably) have multiple keys with the same email or name.Swab
@KennyEvitt never use short key IDs, as OpenPGP key collission attacks are possible.Strudel
@JensErat "never use short key IDs" is good advice if I was or had downloaded keys from an un-trusted source. All of the keys in my key-ring are keys I have myself generated. If an attacker can modify those key files I'm already compromised.Swab
There might be specific use cases where you can be sure about you will never import keys by accident -- but this is not generally true. Mail clients automatically fetching keys, drive-by-imports of keys when only expecting signatures, ... If those additional 128 bits are too expensive to be stored, you've get a very interesting use case; otherwise go on the safe side and always store the full fingerprint especially for all programmatic access. Requirements change fast, you might need to import untrusted, unverified information into your GnuPG keyring later on.Strudel
@JensErat Fair enough; but gpg --list-keys only prints the short IDs. How can I easily list the long IDs?Swab
I already described this in the post linked above (security.stackexchange.com/q/84280/19837).Strudel

© 2022 - 2025 — McMap. All rights reserved.