128 bits entropy passphrase is enougth safe for online storage?

[thoushed]

Let's imagine that for some reason I don't have a safe place to store my seeds + passphrases and I decide to encrypt it with gpg (aes-256) using a 128-bit entropy password (12 words diceware list) and upload it to google drive

I would write that password on a piece of paper that I could carry and memorize it

I know it is not recommended, but would it be safe enough against any type of attack even from qualified attackers such as governments, NSAs, cluster servers, bitcoin miners?

sorry for my english, tranks

[bob123]

GPG is not an algorithm.
So, it really depends on the cipher used.

Usually, for backups, you want to use symmetric ciphers (e.g. AES or CAST5, both were/are standards used by gpg under linux).

Encrypting a file (or data, generally) asymmetrically is rarely needed. What you usually do is to encrypt the data/file with a symmetric cipher and encrypt that symmetric key (which is way shorter than an asymmetric one) with an asymmetric cipher.
Symmetric crypto is way faster than asymmetric one.

To at least partially answer your question, the security of keys compared (by the NIST):

(source)

Bitcoin is using 256 bit EC keys. So, using AES with 128 bit keys is roughly as secure as EC with 256 bit keys.
And both are considered secure by the NIST (and the rest of the world). (Source: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf)


Now, to finally answer your question: It depends on the algorithm. 128 bit AES is secure. 128 bit RSA is not.
You want to have a bit strength of at least 128 bit and you are fine.


However, the encryption is not everything you need to worry about. A few additional things would be:

• Where is the decryption key stored?
• Is your PC definitely not compromised upon encryption?
• How do you generate the key (TRNG, dice)?
• How has your seed been generated (TRNG)?

P.s. Even quantum computers won't break AES 128 bit. Fully functional quantum computers will reduce the search space from 2¹²⁸ to 2⁶⁴ which is still far away from being broken / insecure.

[NotATether]

TL;DR there are only two ways a GPG encrypted file can get compromised: By guessing the password or by using a backdoored GPG with a crippled AES cipher (or a vulnerable version of GPG that leaks AES keys). If you construct your diceware password without a computer and use a recent official GPG build with the default settings you should be safe. And also, you only need 10 diceware words to get 128 bits of entropy, each word is about 12.92 bits of entropy so 12 words will actually give you more, about 155 bits of entropy.


First let's assume the attacker does not know you used diceware.

For guessing the password, an attacker who knows nothing about it's composition will just run a brute force attack with every combination of graphical ASCII characters, and you can figure out that this takes too long to succeed.

There are 128-32-1=95 printable ASCII characters people usually make passwords from. So they make 95^1 + 95^2 + ... + 95^(N, the max length of password they're willing to crack) guesses to get the password. It's an astronomical number of guesses they have to make so we can rule out the possibility of someone successfully doing that for not small N. Even if they only tried cracking N length passwords they still have to do 95^N guesses.

Now let's assume they do know you used diceware and that your entropy came from things like coin flips and dice rolls so that the entropy is truly random. Even if they knew that and also how many words are in your diceware phrase, they still have to make 7776^(number of words) guesses to exhaust the entire random space. A diceware list has 7776 words in it.

So if you use 12 words in your diceware, and each of the words are on average 6 characters long, then they have to make 7776^12 = about 2^155 diceware guesses, or without using any diceware knowledge, a 95^(6*10+ 5 spaces) = 2^427 65-character brute force guesses (or an uncountable number of layman's 1,2,..,65-character brute force guesses). So the size of the random space to search dramatically drops with diceware but that isn't sometime to worry about because it's still too high to be exhausted by modern machines in the foreseeable future.


The AES cipher implementations used in GPG should be secure, given that there aren't any reported CVEs about it on https://www.cvedetails.com/vulnerability-list/vendor_id-4711/Gnupg.html. In fact, there are only 27 vulnerabilities reported on the entire program.

If you want maximum security you should download the GPG binaries or compile their source from their website, and verify the signature of what you download to make sure it's official. There have been cases of linux distributions getting compromised and delivering malicious packages so someone can theoretically replace the bundled official GPG with their own flawed GPG release. However, that particular case hasn't happened yet so if you only have a bundled GPG it should be safe to use that too (until such a case does play out, then I personally would migrate away from the impacted distribution).

In any case, if someone steals the encrypted file from Google drive, they have to go through all of the above labor to crack open the file.

P.s. Even quantum computers won't break AES 128 bit. Fully functional quantum computers will reduce the search space from 2¹²⁸ to 2⁶⁴ which is still far away from being broken / insecure.

AES-256 can still withstand quantum computers because Grover's algorithm used in quantum computers would break it in 2^128 rounds. I don't think there's an optimization to half the AES-192 search space yet, at least according to stack exchange.

[thoushed]

GPG is not an algorithm.
So, it really depends on the cipher used.

Usually, for backups, you want to use symmetric ciphers (e.g. AES or CAST5, both were/are standards used by gpg under linux).

Encrypting a file (or data, generally) asymmetrically is rarely needed. What you usually do is to encrypt the data/file with a symmetric cipher and encrypt that symmetric key (which is way shorter than an asymmetric one) with an asymmetric cipher.
Symmetric crypto is way faster than asymmetric one.

To at least partially answer your question, the security of keys compared (by the NIST):
https://www.securitylearn.net/images/keysizes.png
(source)

Bitcoin is using 256 bit EC keys. So, using AES with 128 bit keys is roughly as secure as EC with 256 bit keys.
And both are considered secure by the NIST (and the rest of the world). (Source: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf)


Now, to finally answer your question: It depends on the algorithm. 128 bit AES is secure. 128 bit RSA is not.
You want to have a bit strength of at least 128 bit and you are fine.


However, the encryption is not everything you need to worry about. A few additional things would be:

• Where is the decryption key stored?
• Is your PC definitely not compromised upon encryption?
• How do you generate the key (TRNG, dice)?
• How has your seed been generated (TRNG)?

P.s. Even quantum computers won't break AES 128 bit. Fully functional quantum computers will reduce the search space from 2¹²⁸ to 2⁶⁴ which is still far away from being broken / insecure.

Thanks for the answer I forgot to mention that I would use symmetric AES 256, and my question was if a key composed of 12 words from the diceware list would be secure enough

reading I have seen that keys with less than 80 bits of entropy could be broken by specialized attackers.

• the key is store in a paper and in my mind
• 1 pc used exclusively with bitcoin, not internet connection ever
• i generate the key with method diceware.
• the seed is generated in the same computer with a checked version of electrum

[thoushed]

TL;DR there are only two ways a GPG encrypted file can get compromised: By guessing the password or by using a backdoored GPG with a crippled AES cipher (or a vulnerable version of GPG that leaks AES keys). If you construct your diceware password without a computer and use a recent official GPG build with the default settings you should be safe. And also, you only need 10 diceware words to get 128 bits of entropy, each word is about 12.92 bits of entropy so 12 words will actually give you more, about 155 bits of entropy.


First let's assume the attacker does not know you used diceware.

For guessing the password, an attacker who knows nothing about it's composition will just run a brute force attack with every combination of graphical ASCII characters, and you can figure out that this takes too long to succeed.

There are 128-32-1=95 printable ASCII characters people usually make passwords from. So they make 95^1 + 95^2 + ... + 95^(N, the max length of password they're willing to crack) guesses to get the password. It's an astronomical number of guesses they have to make so we can rule out the possibility of someone successfully doing that for not small N. Even if they only tried cracking N length passwords they still have to do 95^N guesses.

Now let's assume they do know you used diceware and that your entropy came from things like coin flips and dice rolls so that the entropy is truly random. Even if they knew that and also how many words are in your diceware phrase, they still have to make 7776^(number of words) guesses to exhaust the entire random space. A diceware list has 7776 words in it.

So if you use 12 words in your diceware, and each of the words are on average 6 characters long, then they have to make 7776^12 = about 2^155 diceware guesses, or without using any diceware knowledge, a 95^(6*10+ 5 spaces) = 2^427 65-character brute force guesses (or an uncountable number of layman's 1,2,..,65-character brute force guesses). So the size of the random space to search dramatically drops with diceware but that isn't sometime to worry about because it's still too high to be exhausted by modern machines in the foreseeable future.


The AES cipher implementations used in GPG should be secure, given that there aren't any reported CVEs about it on https://www.cvedetails.com/vulnerability-list/vendor_id-4711/Gnupg.html. In fact, there are only 27 vulnerabilities reported on the entire program.

If you want maximum security you should download the GPG binaries or compile their source from their website, and verify the signature of what you download to make sure it's official. There have been cases of linux distributions getting compromised and delivering malicious packages so someone can theoretically replace the bundled official GPG with their own flawed GPG release. However, that particular case hasn't happened yet so if you only have a bundled GPG it should be safe to use that too (until such a case does play out, then I personally would migrate away from the impacted distribution).

In any case, if someone steals the encrypted file from Google drive, they have to go through all of the above labor to crack open the file.

P.s. Even quantum computers won't break AES 128 bit. Fully functional quantum computers will reduce the search space from 2¹²⁸ to 2⁶⁴ which is still far away from being broken / insecure.

AES-256 can still withstand quantum computers because Grover's algorithm used in quantum computers would break it in 2^128 rounds. I don't think there's an optimization to half the AES-192 search space yet, at least according to stack exchange.

Thank you very much for your answers.

I understand that you mean that the version I use of gpg has some vulnerability or has been modified.

I use the version that ubuntu brings by default, I have not reviewed the code because my coding level is not good enough, but I understand that having many eyes looking is relatively safe.

Thanks once again, have a nice day.

[NotATether]

Thank you very much for your answers.

I understand that you mean that the version I use of gpg has some vulnerability or has been modified.

I use the version that ubuntu brings by default, I have not reviewed the code because my coding level is not good enough, but I understand that having many eyes looking is relatively safe.

Thanks once again, have a nice day.

All code that is committed to Ubuntu packages is signed by a developer's GPG key on Launchpad so I consider those safe to use without having to verify them yourself.

[Abdussamad]

Let's imagine that for some reason I don't have a safe place to store my seeds + passphrases and I decide to encrypt it with gpg (aes-256) using a 128-bit entropy password (12 words diceware list) and upload it to google drive

I would write that password on a piece of paper that I could carry and memorize it

I know it is not recommended, but would it be safe enough against any type of attack even from qualified attackers such as governments, NSAs, cluster servers, bitcoin miners?

sorry for my english, tranks

not really because all they have to do is pick your pocket

btw bitcoin mining hardware can't be used to hack wallets.

[namarang]

making your password super-strong has diminishing returns. It only does you so much good to have the strongest passphrase in the word if you're vulnerable to much easier attacks. That's how you'd justify the much more convenient 14-character password over the 20-character one.

[NotATether]

making your password super-strong has diminishing returns. It only does you so much good to have the strongest passphrase in the word if you're vulnerable to much easier attacks. That's how you'd justify the much more convenient 14-character password over the 20-character one.

It took me a few days to find time-to-crack calculations for these kind of phrases.

In terms of the time it takes to run a brute force attack on passwords 14 characters long vs. 20 chars long, you are right in saying that someone can justify using the shorter password if that's the only attack they run, since even a basic alphanumeric password that's 13 characters long takes 64 years to try all combinations, at least according Timothy Keith  and Jeff Atwood's blog posts. Given the rate the combinations exponentially blow up even if you add one character, I assume it will take an unreasonably long time to brute force even a 14-character password without much letter/digit/symbol variation.

But hackers are smarter now, dictionary attacks are much quicker to carry out on short and simple passwords like these and even makes cracking the 20-character password feasible. They have in their lists pretty much every phrase a normal person can think of from their head. So now we're talking in terms of how fast a hacker can go though their list instead of all the combinations of words, which can be done in a matter of hours if they stole the password hash.

Many people stay signed in to whatever is password-gated, or write down their password somewhere nearby, or even told their relatives their password, so it doesn't even matter how strong your password is if hackers have that sort of avenue to get in. I have a feeling that dictionary lists have less and less of longer phrases in them, so even if you take a simple-looking password, and randomly replace a few letters from it with digits, you can foil most dictionary attacks by not having it on the list.

In other words, a 14-character password you generate from random characters is safer from dictionary attacks than a longer password made from obvious-looking words ("correcthorsebatterystapler", for time's worth!)

Still, I don't agree that someone with poor security hygiene would justify using passwords as long as you'd mentioned, because those people probably don't have good memory retention in the first place, and would use an obscenely short password that doesn't require much effort to remember.

[pooya87]

In terms of the time it takes to run a brute force attack on passwords 14 characters long vs. 20 chars long, you are right in saying that someone can justify using the shorter password if that's the only attack they run, since even a basic alphanumeric password that's 13 characters long takes 64 years to try all combinations,

when speaking of passwords and how long it takes to break them you can't just talk about their length alone. you should also talk about the way they are stored which can make a lot of difference in the amount of time and the complexity of a brute force attack.
for example if the passwords are stored as a simple MD5 hash then it will be millions of times faster to brute force them compare to if they were stored using an expensive KDF such as scrypt with a simple salt.
(the third paragraph in the first link you posted points this out too)

you can easily test this. start 2 different threads in your program and compute equal number of hashes on one thread using MD5 (or any other hash algorithm like SHA256 even) and use scrypt on the other. then see which one ends first and what the time difference between them are.