After reading this post, I understand that a password's entropy depends on the assumptions made when it is to be attacked (e.g. if it is generated randomly from a list of 2048 words, etc.).

Let's suppose an attacker managed to enter some users' cloud storage and found some symmetrically encrypted files. Which assumptions, to attack the password by brute force, would be reasonable for the attacker to make? For instance, since it is a symmetric encryption, a reasonable assumption is that the password has been brain-generated. I imagine this fact generates a subsequent set of assumptions about the password.

Knowing these assumptions, is there any way of calculating the actual entropy of a brain-generated password?

2 Answers 2


Trying to calculate a numeric value for the entropy of a password only makes sense if you understand the actual mechanism that is used to generate it. For example, it's relatively easy to work out the entropy for a password that's created from 3 random words out a list of 20,000, or that's created by choosing 8 random alphanumeric characters.

But you can't really work out a number based on "brain generated", because that covers a huge variety of different possible approaches. And even if you know the approach they use (such as picking a random word, and then sticking a digit on the end), humans can't do "random".

There also an unknown factor that people create passwords differently in different contexts. Most people will try and create (what they think is) a more secure password for their online banking than for some random forum they don't care about. So it's not enough to know how an individual creates passwords; you need to know how they created this password.

You could potentially try and calculate some kind of number based on how hard is was for you to crack that password - but that number would depends largely on how you were trying to crack it, so will be very variable.

TBH, any kind numeric value for the strength of a password should be taken with a big pinch of salt, and even more so if it's not a password that was computer generated.

So I think you'll struggle to calculate any kind of meaningful value - which leads to the question of what you're trying to achieve by doing so?

  • Thanks. I'm trying to understand how more unsecure would be to store a cryptowallet seed on the cloud compared to have it in a piece of paper at home, provided that the cloud seed is first encrypted with AES256, with a "human-generated" "strong" password. By strong I mean more than 20 characters (upper, lower, numeric and special).
    – Dan
    Commented May 6, 2023 at 13:18
  • @Dan are you talking about technically enforcing those requirements, or just hoping that users will follow them? Because there's always going to be someone who tries to set a password of Password1234567890 or similar. But if you're trying to think about how secure something is, then you need to thinking about what your threat model is. Or to put it another way, how secure against what?
    – Gh0stFish
    Commented May 6, 2023 at 14:39
  • Particularly answering "how secure against what?", my biggest concern is that some attacker gains access to the file and downloads it, so it can try to attack its password by brute force offline. I'm comparing that scenario with the chances of me losing the HW wallet when moving to a new flat, or failing the pin too many times. These chances can be high in my case, as I think I have a tendency to be scatterbrained.
    – Dan
    Commented May 6, 2023 at 16:21
  • About enforcing requirements or hoping that user will follow them, that's not my goal. My goal is to store my seed in a place I know will be there even if a move to a new house, new city etc. Cloud is ideal for that, but at the same time extremely risky according to almost everyone in the crypto world
    – Dan
    Commented May 6, 2023 at 16:23
  • @Dan if you're using a decent KDF then that should make make brute-force attacks against the encrypted files much harder, and since these files would only be needed during the initial setup or recovery you can afford for that to be slow and expensive. And of course, there are lots of things you can do to try and stop an attacker from getting hold of the files to be able to attack them in the first place, like encrypting them yourself and storing your keys in a HSM.
    – Gh0stFish
    Commented May 6, 2023 at 16:51

This answer pertains to this question, and the similar question at https://security.stackexchange.com/questions/270052/how-unsecure-actually-is-to-store-crypto-currency-seeds-in-cloud-provided-that.

Instead of creating a random bitcoin private key, then using a password to derive and AES256 key, then using the AES256 key to encrypt your bitcoin private key, then storing the encrypted bitcoin private key on someone else's server - you might want to consider using a brain wallet to derive a bitcoin private key directly from a password (or passphrase). This eliminates the need store anything.

AES256 keys and bitcoin private keys are both 256 bits in length. So the same key derivation functions (KDFs) that are used to derive AES256 keys from passwords can be used to derive a bitcoin key directly from a password (or passphrase). So, if you are concerned about a brain wallet program that you are using noe becoming deprecated in the future, you can simply use a standard key derivation function (such as PBKDF2, Bcrypt, Argon2, etc.) to derive a bitcoin private key from a passphrase. If you want to store the bitcoin private key as a backup (in case you forget the passphrase), you can.

IMPORTANT: If you decide to go this route, be sure to use a strong KDF (such as Argon2 with a very high cost factor), and be sure to use a strong high-entropy passphrase. Once your bitcoin address has coins associated with it, there will be actors with lots of computing power trying to crack your key, so both of the above are critical to slowdown such attacks.

You must log in to answer this question.

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