Page MenuHome GnuPG

Add a way to generate keypairs from a passphrase
Open, NormalPublic


Release: 1.2.1




I propose adding a way to generate a keypair where the private key is generated directly from a passphrase. It should generate and save a public key in the pubring file in the usual way. Saving a secret key in the secring should be optional. The idea is to be able to decrypt without needing a secring file. This is very useful, as evidenced by the fact that people still use the -c option (conventional symmetric encryption) even though you need the passphrase for both decryption and encryption. It would be good to not need the passphrase for encryption. An example application would be an automatic backup script. You would generate encrypted backup files without needing any secret keys. Then if your computer crashes or melts, you can buy a new computer, install a new OS on it, install GPG on it with no key files, and still be able to recover your backups. Anyone who's used GPG/PGP for a long time knows that this kind of thing happens more often than it should. I think the reason PGP didn't have this feature in the beginning is that RSA key generation (the only public-key algorithm then supported by PGP) on those old computers was very slow. But these days, generating an El-Gamal key from a passphrase is very straightforward (just use a hash function) and even generating an RSA key is reasonably fast (because computers are faster now). So I think this would be a worthwhile addition. I'm willing to come up with a patch if the maintainers would like to integrate it.





Event Timeline

werner added a subscriber: gnupg-hackers.

I will consider this

Its indeed possible but I am not sure whether we will
implement it for 1.4. It is more likely that it will be
done with the help of libgcrypt and thus sometime appear in
gpg 1.9

werner removed a project: gnupg.

Moved to libgcrypt until we have implemented this feature.

Implemented in Libgcrypt trunk.

Now we need to enhance gpg2 to make use of it (decryption part).
The idea is to use one of our special key protection modes and have gpg2
regenerate the secret key from the private one and the passphrase.

werner set Due Date to Mar 31 2007, 2:00 AM.Mar 5 2007, 4:24 PM
werner changed Due Date from Mar 31 2007, 2:00 AM to Jun 15 2007, 2:00 AM.May 7 2007, 3:43 PM
werner changed Due Date from Jun 15 2007, 2:00 AM to Dec 15 2007, 1:00 AM.Sep 11 2007, 10:15 PM
werner changed Due Date from Dec 15 2007, 1:00 AM to Mar 31 2008, 2:00 AM.Dec 11 2007, 6:17 PM
werner changed Due Date from Mar 31 2008, 2:00 AM to Mar 31 2009, 2:00 AM.Sep 30 2008, 7:45 PM
werner removed Due Date.
werner removed a project: In Progress.

The change werner mentioned previously is eaba8d58acda66f428870794115cb22c2590ec5e, but this is based on Elgamal. RFC4880 since then specified S2K, and better approaches are available, too (at least PBKDF2 is in libgcrypt). These could be used with HKDF for RSA and other asymmetric key generation methods.

werner lowered the priority of this task from Normal to Low.Jul 4 2017, 3:43 PM

FWIW, OpenPGP's S2K and PKCS's PBKDF2 are very similar and don't make a difference except that we have calibration code for S2K in gpg-agent.

It would be great if this feature were implemented with a mnemonic code option, with a built in checksum, as described in bip39: Using the same bip39 standard (and perhaps others, as alluded to in T3497) would also improve compatibility with existing crypto key storage devices (i.e. cryptocurrency wallets used as smart cards).

The combination of mnemonic codes and a checksum are very useful in the whole process of generating a random code on airgapped hardware, transcribing it to paper by hand, and entering it back on a machine when the secret key is required again.

Bonus points if the same could be done for the public key.

My use case is much like the one described by the original author of this task: I wish to generate a random key on an airgapped device in volatile memory, write down the mnemonic code on paper, and transfer the public key to my less-secure device. Then I want to use the public key to encrypt backups which will be kept in untrusted storage. The secret key will exist only on paper until I need to recover from a disaster.

I'm finding it surprisingly hard to do this securely with current software.

werner raised the priority of this task from Low to Normal.Jul 18 2018, 10:04 AM

The problem with mnemonics based on words is that they are language dependent and only a small part of the world is fluent enough in English to spell/use them correctly. Thus anything based on ICAO spelling (Alfa, Bravo,...) is a better choice than arbitrary words from one language. Even if that meas to write down a longer string. A CRC is of course very useful.

Anway, I t seems that there is more interest in such a feature.

Mnemonics can be made language independent by implementing wordlists for every language. In bip39, each word represents a number, 0 through 2047 (their index in the wordlist).

They actually do that for English, Italian, French, Spanish, Korean, Chinese (both traditional and simplified) and Japanese languages. They also have special considerations for each, as an example, all words in all latin-alphabet-based languages can be uniquely identified just from the first 4 letters, reducing mispellings.

More on how it was done on bip39:

And the considerations they made when generating wordlists for each language:

Hi everyone,

We ( open-sourced a C++17 based PGP packet library. Using the library, you can create packets, encode and decode packet data and create a PGP key from e.g. a raw elliptic curve point. We've seen quite a lot of bad publicity for PGP lately, but we hope this helps those who are stillf using it. Lo and behold:

As a user I think that this capability would be a great addition to PGP and it might even make it a standard tool for key generation across cryptocurrencies.

Furthermore the bip39 format easily lends itself to splitting groups of words between family members or other trusted individuals and to be used for general encryption of anything that one may wish to be retrievevable by next of kin in the absolute worst case scenario.