I have been using a key pair at home with gpg command line tool on Ubuntu, to encrypt password text files for a few years now. I no longer have any record of the type of encryption and bit length used when I created the keys so I would like to identify it and decide whether the encryption is strong enough for the next step, or whether I should create a stronger key pair and re-encrypt a bunch of files which I'd like to avoid.

The next step would be uploading the key pair as well as all passworded files to cloud hosting, probably Google Drive. I assume that the cloud hosting may not be fully trust worthy and I need to maintain high encryption. Given that requirement, is a long passphrase (over 32 chars) enough to secure the private key?

  • why on earth would you upload your private key on a cloud service? To answer your question: If you feel current parameters aren't strong enough, they aren't. Create a new key. Plus gpg doesn't use your password during key generation, it only uses it to recall (decrypt) the local copy of the key (unless i'm mistaken). Keep your keypair, especially your private key, on a secure off-cloud location, like your workstation, and then upload your files. It's generally good practice to renew your keypairs every year or so anyways.
    – rath
    Commented Jan 2, 2014 at 15:04
  • 1
    My private key is locked with a long passphrase, I wouldn't upload it to the cloud raw. I've discovered my key is 2048bit RSA so I'm feeling a bit more confident about it now. I was advised by a friend in fact that I could simply reapply a much longer passphrase to cloud stored private key.
    – DanH
    Commented Jan 3, 2014 at 16:22

1 Answer 1


is a long passphrase (over 32 chars) enough to secure the private key?

If it's cryptographically random, and has a large character set, then probably, unless a flaw is found. Note that I would consider putting my secret key on someone else's machine a very high risk to begin with, and a risk even if I wrapped it inside another layer (7-zip or Truecrypt or something else). The most secure practice is to keep the main private key entirely offline and only let subkeys out onto network connection machines, though that can be cumbersome.

whether I should create a stronger key pair and re-encrypt a bunch of files which I'd like to avoid.

There are three levels of encryption to think about:

  • asymmetric encryption: This is used for signatures, as well as to encrypt the randomly generated key PGP/GPG use for symmetric encryption (of files)
    • You've identified this as RSA 2048, which as of March 2014 is "acceptable" for the forseeable future per U.S. NIST SP 800-131A and rated as "103 bits" of security (where "84 bits" is the minimum [few months of protection] level if your adversary has a $300 million budget) ECRYPT II Yearly Report on Algorithms and Key Lengths (2012), so that seems fine.
    • "gpg --list-keys" shows this automatically - 2048R means 2048 bit RSA, and 4096R means 4096 bit RSA.
  • symmetric encryption (of files): This is up to a combination of your public key's preferences and the capabilities of the gpg/pgp softare you use. Since you're presumably using software with equal or better capabilities to what you used to generate the keys, this will be the first cipher in the list.
    • "gpg --edit-key [key]" followed by "showpref" will show this in human readable form.
    • within the edit-key section, you can use setpref to change these with a space-delimited list of ciphers, hashes, and compression algorithms.
    • This is 100% an aspect of the PUBLIC key and can be changed at any time - you can, in fact, have different public keys for the same secret key with different options, and all will work.
    • See GnuPG.org, Managing your own keypair
    • "gpg -vv [encrypted file]" will, in addition to decyrpting the file, actually show whatever was actually chosen to encrypt a given file - first it'll display (in your case) "gpg: encrypted with 2048-bit RSA key..." and then it'll display "gpg: [algorithm] encrypted data"
    • The above references agree that all AES key lengths are fine. Three-key TripleDES is good through 2030 per the 2012 ECRYPT II analysis. CAST5 was not analyzed. CAMELLIA was not analyzed, but AFAIK is considered secure at this time; it's a European and Japanese cipher used in their standards instead of the U.S. AES cipher.
  • symmetric encryption (of your secret key, by your passphrase): This is the password hasing + encryption of your secret key.
    • "gpg --list-packets ~/.gnupg/secring.gpg" can be used to see this (change the path to your own secret keyring, of course)
    • Note that GPG 1.4.12 is listing "SHA1 protection" even when it lists "hash: 10" (i.e. SHA-512) as well.
    • "gpg --cert-digest-algo sha512 --s2k-cipher-algo CAMELLIA256 --s2k-mode 3 --s2k-digest-algo SHA512 --s2k-count 40480000 --gen-key" would, for instance, allow creating a fairly secure key.
    • "gpg --s2k-cipher-algo CAMELLIA256 --s2k-mode 3 --s2k-digest-algo SHA512 --s2k-count 40480000 --edit-key key" followed by "passwd" and saving a passphrase change (even to the SAME passphrase you have now) will change the encryption protecting an existing secret key.
    • Note that GPG tends to round --s2k-count up to a value it considers valid.
  • Thanks for the comprehensive answer! Obviously my question is not targeted at minimizing risk of breach outright, but trying to find a balance between the risk of breach and risk of dataloss, i.e. The loss of my private key and/or encrypted files due to disaster.
    – DanH
    Commented Feb 25, 2014 at 4:34
  • 1
    You're welcome. For DR, you can also, or in addition, try keeping your private key on an encrypted USB drive. There are actually a handful of FIPS 140-2 validated ones, like the Apricorn Aegis Secure Key. Likewise, you could print the encrypted private key out on paper and put it in a safe deposit box - credit to Where do you store your personal private GPG key? Commented Feb 25, 2014 at 4:48

You must log in to answer this question.

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