How does the security of a GPG2 hybrid-encrypted file compare to a LastPass vault?

Question

While discussing LastPass, a colleague told me about trousseau, a GPG-based method of sharing key-value stores between developers on shared sites/cloud drives/etc. How do the two compare in terms of security assuming an attacker can get hold of the encrypted vault files and possibly the encrypted GPG private key.

From what I understand, this is how LastPass and GPG encryption work:

LastPass

rounds = user-defined (default: 5000)
encryption_key = PBKDF2(HMAC-SHA256, passphrase, username, rounds)
Vault = AES-256(encryption_key, data)

Attack vectors:

• passphrase
• vault

GPG2

# Vault
encryption_algorithm = CAST-128 (CAST5) in gpg2 stable or AES-128 in gpg2 "modern"
encryption_key = <128 bits, randomly generated?>
Vault = RSA-2048/3072/4096(encryption_key) || CAST-128(encryption_key, data)

# Private Key
rounds = <stored unencrypted in the key file>
     From the gpg manual, "the default is inquired from
     gpg-agent", and then no other information is given. It
     appears to be calculated to be the number of rounds taking
     100ms to execute on the machine that placed the protection on
     the key. (Source: <https://bugs.gnupg.org/gnupg/issue1800>)
     rounds = 18,874,368 on my 2012 MacBook Pro (2.6 GHz Intel i7)
salt = <64 bits stored unencrypted in the key file>
encryption_key_for_private_key = PBKDF2(HMAC-SHA1, passphrase, salt, rounds)
encryption_algorithm_for_private_key = CAST-128 (CAST5) or AES-128 depending on gpg version

Attack vectors:

• RSA-encrypted symmetric key
• private key passphrase
• vault

Question

Based on the attack vectors, how do they compare? I'm trying to better understand how they work and what the trade-offs might be using one over the other and then later I'm altering the question slightly asking what differences are made by changing GPG's default settings to be even stronger.

• HMAC-SHA256(10^3 rounds)
• HMAC-SHA1(10^6 rounds)
• RSA-2048/3072/4096
• CAST-128
• AES-128
• AES-256

Extra

It appears that the algorithms used by GPG2 are based on values stored in the private keys. Would it be beneficial (or overkill?) to use values like these?

--s2k-digest-algo SHA256 --s2k-count 65000000 --s2k-cipher-algo AES-256

That switches the private key passphrase stretching algorithm to SHA256 using over 65 million rounds and uses AES-256 encryption to encrypt the private key.

Answer 1

For both "tools", the attack vector on the passphrase heavily depends on its length, hence you should specify it for exact comparison. In any case, using a random 12 char password ([a-zA-Z0-9] and special chars) makes both key stores secure against the biggest clusters of graphic card clusters that would try to brute-force it over the next centuries. Checkout a zxcvbn-based password test tool to get an impression.

So the answer to the passphrase attack vector would result in something like "LastPass vault crackable if <=8 char random password, GPG2 method still safe if >=6 char random password". Applying even more rounds of SHA256 (as you suggest in your "Extra" section, which is also possible to configure with LastPass) may bring you to a point where a 7 char random password might still withstand attacks for a long time. Know that your attackers will use dedicated hardware and software that is optimized to calculate SHA256 either in graphic cards or ASICs, but they're powerless against math, which means the longer the passphrase string is, the sooner there won't be away to "ever" crack it.

So assuming your password is fine (>= 12 random chars or a very long string of randomly selected words), there is no more difference in the two approaches (besides the unnecessary additional waiting time for password verification due to higher amounts of hashing rounds), you must consider the next attack vector, which is the extraction of the plain text password during usage. You have to think about the first contact point (your Keyboard where you type it in - think about keyloggers!) until the last contact point (the password in your browser's LastPass plugin before it's being hashed or the console where you type your password to unlock the trousseau vault). As there's one more step (so an additional attack vector) with LastPass, which is the malicious replacement of your LastPass plugin with a fake plugin that would send your plaintext password to another party), you could say that GPG2 has a little advantage. The point of the keylogger is, of course, only valid if you type your password. If you copy&paste it from yet another tool,

About the vault: With LastPass your vault is stored on dedicated backend machines on the servers of LogMeIn. A very sophisticated attacker or an internal LastPass employee could potentially access your vault (this has already happened in the past) and start the password guessing attack. For GPG2, this depends on where you'll place your file. With both approaches you can safeguard the accessibility of the files with 2-factor-authentication (LastPass 2FA, also with hardware security tokens; Dropbox 2FA with Google Authenticator), but beware that not everyone who you share the vault with use 2FA. Here you're also comparing AES-128 to AES-256, and for both attacks, using a proper implementation and configuration (which we would assume is fine with both solutions), you're safe for centuries and an attacker will usually achieve his goal faster by breaking the hash before the AES encryption. So the next data security question is availability of your vault. Besides the availability of the LastPass service and the location where you store your GPG2 vault, you'll have to think of accidental deletion, from which restoration is usually hard if you don't have your own backups. If you only store your GPG2 vault in DropBox, an attacker who gains access to your account would be able to delete the file, wait until the deletion syncs to all parties, delete the file with its history forever and close the DropBox account. The same could happen with a LastPass account, so have a good backup strategy for your vaults, or you'll be praying that you thought of activating offline login with LastPass, which would help you gain access in some browser where you have not yet logged in since the attack (don't forget to actually be offline, else the deletion sync could start).

RSA-encrypted symmetric key: I guess you haven't considered this, but under the hood LastPass is also making use of asymmetric encryption, probably also RSA (you'll have to reverse-engineer the Plugins to be sure), so this is also an attack vector for the LastPass vault. Here it boils down to proper key generation, and this is more transparent with GPG2, especially regarding the entropy pool used for key generation. Looking at the strangely lower-than-expected-entropy of the generated passwords in LastPass and their fall-back to insecure methods if the Web Cryptographi API is not available in the browser, my trust in high-entropy asymmetric keys lies not with their tooling.

So to summarize: It all boils down to the strength of your password and how you handle it. If that part is good enough, you're unnecessarily prolonging the time required to get to your data in the vault by applying more rounds or using stronger encryption algorithms. You lose the least calculation time by changing from AES-128 to AES-256, so that's a thing I would go for. In the end you'll probably decide for a the tool that has the best usability and availability, and maybe you'll care more that you can access the data on your mobile phone or tablet with the LastPass app (this is usually not solved on mobile devices for GPG, or very hard to accomplish in a usable way) than a more open solution with GPG2.

The overall question is much less about applying even better algorithms if the key problem is already solved (password handling). You could either have everything under your control (GPG2 with your own server hosting the vault, making sure your tooling doesn't change without your knowledge), or delegate some control to a third party (LastPass hosting and browser plugin updates) as a trade-off for better usability and less maintenance effort.