Backup + AES-128 encrypted file in Cloud sync

Question

I've some data that I want to backup to the cloud. I also have a file containing personal data, that I need to sync across multiple devices. At the moment, for this file, locally in my computer, I've already been using GnuPG to encrypt the file with a symmetric cipher (AES128) with a passphrase. Passphrase is 16-chars long (has numerics, symbols, pronounceable words). Don't want to use a longer passphrase.

Would it be safe to move a thus AES128 encrypted file to the cloud? i.e., I will simply copy over this file to a cloud sync service like dropbox. Assuming someone has access to this file, how difficult will it be to crack it?

I intend to backup a lot of data onto Google Drive. This will be done via Borg backup encrypted with repokey (AES-CTR-256 for encryption and HMAC-SHA256 for authentication in an encrypt-then-MAC (EtM) construction). The passphrase that was used for this will be stored in the file mentioned in #1 above, which will also be synced to my Google Drive.

Answer 1

As is often the case, the critical factors are the strength of your password and the strength of the key derivation function that GnuPG uses to derive an AES key from your password.

You mention that your password is 16 characters long, consisting of uppercase letters, lowercase letters, digits, and symbols. Therefore, there are ~80 possible characters, so your password space is ~80 ^ 16, which is 2.81 * 10^30.

By default, the KDF used by GnuPG uses 65536 rounds of SHA1 hashing (see https://crypto.stackexchange.com/questions/9985/kdf-and-number-of-iterations-for-gpg and Brute-force a passphrase, generated by `pwgen 16 -s`, of a GPG CAST5 archive). To brute force your password, the attacker would need to try each password in the space, and for each password, do 65536 rounds of SHA1, to generate an AES-128 key from the password. So, the total number of SHA1 hashes needed to generate an AES-128 key for every password in the space would be 65536 * 2.81 * 10^30, which is 1.84 * 10^35 hashes.

The most cost-effective way to do mass-hashing is to use ASIC technology. Let's assume the attacker had the ability to custom-build an ASIC system specifically to hash GnuPG passwords, and could do it at the same cost as commercially-available ASIC systems for Bitcoin mining. In that case, we can use the Antminer S19 as a basis for comparison, which retails for $11,700 and can do 110 terra-hashes per second. At this rate, the number of seconds that it would take to generate an AES-128 key for every password in the space would be 1.84 * 10^35 / 110 * 10 ^ 12, which is 1.67 * 10^21 seconds.

That equates to over a thousand billion years. And bear in mind that this is just for generating an AES key for every password in the space - this doesn't include the time that it would take to try decrypting the ciphertext using each key.

To that end, note that the number of hashes required to generate an AES-128 key for every password in the space (1.84 * 10^35) approaches the key space of AES-128, which is 128 bits (3.40 * 10^38). An attacker might decide it's not worth generating a key for every password in the space, but instead, 'simply' try every key in the AES-128 key space. So, we're back to brute-forcing an AES-128 key, which will also take a very long time.