6

How secure are PGP/GPG encrypted mails?

I realize that it's probably fine for regular e-mail scenarios, but what about the security over longer time periods (>30 years)? Is the 4096 bit limit for RSA keys of GPG going to be an issue (given that there is no way to use symmetric-only encryption)? Also, if I'm not misunderstanding anything, GPG does not authenticate the ciphertext (it only RSA-signs the plain text)?

The usage scenario here is that I want to store passwords in my mail account (as PGP-encrypted mails to myself), in order to have them accessible everywhere. I already use Firefox Sync for most accounts (which uses a rather advanced scheme), but that only stores username/password combinations for one URL. Sometimes I need to save some additional details with that too, and hence can't use FF Sync, despite it being awesome otherwise.

As far as I can see, there's also no other alternative to PGP and S/MIME for mail encryption, is this correct? (S/MIME isn't an option, seeing how poorly supported it is by Thunderbird currently)

user28381
  • 61
  • 1
  • A quick note: you might want to check out [KeyLength](http://www.keylength.com/) as a reference for various recommendations on key lifetimes. You should be alright until 2030 at least on a 4096-bit key, assuming QC and Shor's algorithm don't come along and ruin semiprime factoring. – Polynomial Jul 17 '13 at 09:09
  • Have you already looked at Lastpass (If your goal is to use stored passwords in Browsers) – Marcel Jul 17 '13 at 11:19
  • Also, in your scenario, you could also change Passwords (and the storage of it), if you feel at a certain point in the future, that they are not save anymore. – Marcel Jul 17 '13 at 11:20
  • Have you factored in the truism that the value of information nearly always relates to its timeliness? Who exactly do you expect will be banging away on 30 year old emails trying to break their keys? Key security also depends on the cost/benefit of the effort. – zedman9991 Jul 17 '13 at 11:59

2 Answers2

2

The 4096-bit limit on RSA keys for GPG won't be an issue for security, unless a new, better, faster algorithm for cracking RSA keys is discovered, and then any assertion about strength provided by some specific key sizes would be overly speculative. New algorithms for cracking RSA don't happen often; last time was circa 1989 for the General Number Field Sieve (most of the scientific advances on GNFS since the late eighties' are about practical implementations of GNFS and a lot of small-scale optimizations, but the core algorithm has not changed since that time).

Note that asymmetric encryption does not solve the confidentiality issue; it just moves it around: you still have to store the private key somewhere. Ultimately, for your problem of storing passwords, you will protect your private key with a "master passphrase" and that's symmetric encryption. You could make the whole process simpler by applying symmetric encryption directly on your file full of passwords (GnuPG supports it). Going fully asymmetric is interesting (in your context) only if you want to store a new password from a machine from which you do not have access to the private key and on which you do not want to type your passphrase.

Either way, a tricky point is when it comes to using your stored passwords. You have to perform decryption on some system. That system had better be free of any malware, because a keylogger would then grab your passphrase and/or your private key (if you use asymmetric encryption). Ideally, you should do that only from your own device(s). That's what I do when travelling:

  • My own device is a Linux-powered netbook.
  • The /tmp directory is a memory-based filesystem (so what I write in it never makes it to the SSD).
  • No swap has been configured (so what is in RAM is never written to the SSD either).
  • I decrypt (symmetrically) my file-of-passwords in /tmp, read the password, then type it, and then I delete the decrypted file.

Of course, if you have your own device at that point, why would you need to store the encrypted file in your email ? You could keep it directly on your device.

(Speaking of which, since emails can store arbitrary files as attachments, you do not need to restrict yourself to the email-specific formats OpenPGP and S/MIME. Using these only makes things simpler in that you may hope for your mail application to perform the decryption, instead of having to resort to some command-line tools. However, I may argue that command-line tools give you more control about where your data goes, e.g. in a RAM-backed /tmp filesystem.)

Community
  • 1
Tom Leek
  • 168,808
  • 28
  • 337
  • 475
0

Hopefully I'm not going too far off topic discussing the last part of your question in a little more detail since I think Tom covered everything else.

I also couldn't find any indication that gpg uses a MAC on the ciphertext.

Lately, I've been using the scrypt utility to encrypt a file with a password (both a passwords file and tar files for backups). There is no Windows build that I am aware of (I'd guess cygwin would work), nor am I aware of any other application that supports the particular file format it produces. It is still closer to what I'm looking for than other utility I've been able to find and might work for you. It intentionally has few options; IMO, it could use a verify option since right now you have to decrypt to /dev/null to do that. The documentation isn't great; you have to look at the FORMAT file in the source distribution to find out what it is actually doing, which is running scrypt on the password with random 256-bit salt to get two 256-bit keys, one used for AES-256 in CTR mode with fixed nonce of 0 and the other for HMAC-SHA256. Also, the time estimate used with the -t argument is not accurate; I find I need to use -t 25 to get 5 seconds of key strengthening. The other annoying thing is that it doesn't quite work to pipe decryption output to less, so you need to find somewhere to store the decrypted output when you are looking at it as well as editing it. I've used either a memory file system (with no or encrypted swap, which would be a good idea anyway) or encrypted home directory. It uses the openssl AES implementation and other crypto code copied from the author's other similar utilities but not built as a separate library (which would be nice; someone else did that but I can't find the link right now). The major benefit is that it does the basic "strengthen password then encrypt then authenticate" thing in a fairly small amount of code.

I've previously used but do not recommend seccure, which uses public keys based on elliptic curve cryptography and derived directly from the password (unfortunately via only a single round of SHA256). It looks abandoned, has produced corrupted files, and requires a bunch of locked memory to work. I like what it attempts to do and wish there was a working version of that.

I haven't found good archivers with integrated "encrypt then MAC" and modern crypto that deal with things like file holes and UNIX permissions. I think the situation is better if you only want zip style archiving but I don't have specific recommendations.

Hopefully in the next few years there will be standard widely available utilities to do this kind of thing easily that aren't as complex as the current options and use current crypto.

joveian
  • 131
  • 3