Error with warning under Backup your private key
I took notice of the warning under the header Backup your private key and I am pretty certain it is an error.
Exported secret keys are encrypted using your paraphrase. See the attached link.
Ever notice how you don't need to enter your paraphrase to export a secret key? It's because you're not decrypting it. The secret key you're exporting is still encrypted! Try exporting a key, then import it on another machine (if possible)... Notice that you still need your passphrase on the new machine to actually use the key because the secret key you imported was encrypted. You can't do anything with an encrypted private key. GnuPG will NEVER export a unencrypted private key unless you explicitly ask it to using --export-reset-subkey-password or similar option.
I did see some conflicting information however saying that exported private keys aren't protected. However, they are. I know they are. Look at the source code. Inspect the exported key's packets. It's encrypted. GnuPG isn't that stupid.
I think this warning is an error, and is causing many people to be hesitant to backup their keys.
GnuPG exported secret keys are always encrypted on export. If it wasn't the case, you'd need your passphrase before export to get the raw unencrypted key. In order to preform crypto operations on someone's behalf (especially signing), like the warning states, you'd need their passphrase to the exported secret key.
Before I go ahead and change this page, I just wanted to get some input and see if I'm wrong.
- Hi, thanks for pointing it out. You are right, I think it was a simple hickup referencing old gnugpg releases. The references you use above are not ideal for the same reason, by the way. In particular the first link contains some fallacies in its second paragraph. Also note gnugpg will indeed regain functionality to export the secret-key without the passphrase sometime: , . .. Please don't call them stupid for it now ;) .. as so often security is torn by everyday use cases, it's simple as that.
- I have changed the warning with this edit. How do you like it? You are welcome to edit it freely to improve on it (applies to anything in this wiki, just make sure to ArchWiki:Contributing#Always properly use the edit summary, so that others understand the what and why).
- --Indigo (talk) 10:29, 28 April 2016 (UTC)
- Thanks for editing that. It's great! Hopefully many users now feel comfortable exporting and backing up their private key to a secure medium (just in case disaster strikes).
- Just a quick note. The first bug, while an issue, is mainly irrelevant to the majority to GnuPG users, since it only affects the 2.1 release, which is the modern version. In many distributions, this version is not installed, or if it is, is not the primary version used. The second issue only applies if the key doesn't have a passphrase. This again only affects a small set of GnuPG users as many users choose to use a passphrase with their key (assuming they're aware of good key security practices). GnuPG will prompt the user, confirming that a passphrase isn't desired. But thank you for pointing those issues out, nonetheless (I didn't know they existed before now.)
- While bugs do exist, I'm sure an issue as big as exporting private keys in plaintext would be taken extremely seriously and patched quickly by the GnuPG developers.
- Though you shouldn't fully trust any software, many people rely on GnuPG every single day to protect what matters to them. It's an imortant piece of software to many people, and as a community, we should take every step to ensure the accuracy of the information we're sharing. I might have come off slightly strong in my first post, but I can get that way with serious matters ;).
- Thanks for all your help Indigo!
- Ok, great, thanks for feedback. Closing this item then. Quick reply regarding releases: We don't usually reference release information, it only complicates reading flow. One of the benefits Arch users cherish is having latest stable software releases rolled out to them very fast. It is only natural ArchWiki can be expected and strives to contain up-to-date info everywhere (& thanks to our many contributors who care that works pretty well). For this edit it seemed useful to reference release info, to notify about a new feature with different application behaviour, but it is one of few exceptions really. If you (/anyone) see something else which is outdated but can't fix it right away, putting a status template like Template:Out of date or Template:Accuracy also helps. --Indigo (talk) 10:50, 7 May 2016 (UTC)
inaccuracies in #Encrypt_and_decrypt section
Hey, I am not quite sure about the correctness about some statements in the mentioned sections. At least they are inaccurate about the basic principles of public-key cryptography, wich is in my opinion the main usage of pgp.
The points I am not sure about and where I would like to hear someone elses opinion are: 1) "When encrypting or decrypting it is possible to have more than one private key in use." I think that is not about private but about public keys. You can of course have multiple private keys in you keyring, but I don't know how you can need more than one to decrypt a file.
2) According to 1) the rest of the pragraph doesn't make much sense to me, too. It's true that the '-u' option lets you chose the private key to use. But usually an encrypted file contains informations about the keys it is encrypted with, so you won't need that in most of the cases.
3) "$ gpg --encrypt --armor doc" This command seems also a bit odd to me, because it doesn't specify a recipient. When I enter it gpg complains to me about that and asks me interactively to specify a recipient. I mean there is nothing wrong about it, but it does not convey the concept of public-key cryptography. At least it should be stated, that gpg will ask you for the recipients.
Maybe that wiki page shall not be a tutorial on public-key cryptography, but if you are new to that, you are very likely to be confused by these inaccuracies, I think.
- Hi, I'd say the intention behind the examples in GnuPG#Encrypt and decrypt is to keep it simple, because - as you note - the underlying concepts are too much to more than touch upon in a short section about usage. I agree with you the first sentence can be misleading for users not versed in it (what is meant imo is that often different keys/subkeys are used). I think it would be enough to rephrase it to make that part clearer along what you write. The examples could even stay the same, just adding that gpg will ask for a recipient (encrypt) due to the underlying encryption concept and reference the reader to the typical Alice&Bob examples elsewhere (e.g. wikipedia:Public-key cryptography). Adding then that if one uses the own key-id as recipient, the note about using gpg to protect self-encrypted docs could be merged/lead over to.
- These are just my thoughts on it, please don't refrain from rewriting it in the way you think what is a good basic usage example. --Indigo (talk) 14:55, 10 May 2016 (UTC)
- 1) This section is about private keys and is correct, but I agree that this is far from clear. See .
- 2) It only really applies to the decryption part, although you could use a private key to sign in addition to the encryption(not covered here), so perhaps it should be moved to just it to the decryption section.
- 3) +1 It seems like the recipient was put in the following tip, but should be put in the main section.
- -- Rdeckard (talk), ArchWiki Maintainer 23:57, 10 May 2016 (UTC)
- I've done some editing now. I did my best but since I am noT a native speaker, it would be nice if someone just could check through.
- I omited all the whole '-u' thing, because this option seems to be only relevant to signing (according to the man page of gpg:
-u Use name as the key to sign with. Note that etc.). I guess, if there is no information about the recipient in the encrypted file, gpg will just try out every private key in your keyring, so you do not need to specify it usign '-u'.
- --Ritka (talk) 18:58, 11 May 2016 (UTC)