# Where can I learn basic cryptography to know more about passwords and Bitcoin?

Basically my knowledge in passwords consist of setting up a Diceware master password back then, and I know hashes are not convertible back to the original password.

Some basic question I want to know the answer for is how can a password be predicted from the hash? Like it can be known how many characters long it is exactly or at least roughly?

• If you're interested in learning the intrinsics of Bitcoin. I suggest starting at the technical paper: bitcoin.org/bitcoin.pdf and looking up every term you don't know about yet. Note: this will take some time, so it's not if you just want to be sure your wallet is secure there are shorter paths. – Beanow Mar 20 '13 at 18:36

At the core of your question is a concept called entropy, which is the amount of uncertainty or unpredictability in a set of data.

In cryptography, entropy is related to probabilities, expressed in terms of powers of 2 (bits.) For example, a fair coin flip has one bit of entropy: it can be either heads (1) or tails (0). Flipping four coins gives you one of 16 possible outcomes, so it gives you four bits of entropy. Rolling one six sided die gives you 2.6 bits of entropy ( $2^{2.6} = 6$ ), and so on. Each Diceware word generated with 5 dice gives you $2^{(2.6 * 5)} = 2^{13}$, or 13 bits of entropy. Ultimately, the number of bits of entropy represents the number of tries required to test every possible input (also known as a brute force attack.)

Be careful not to confuse a password with a hash of a password. A SHA-1 hash is 160 bits of data that looks very random, so it might appear to have 160 bits of entropy. If I were to tell my computer to guess every possible value for a SHA-1 hash ( $2^{160}$ ), it would take longer than forever. However, a hash algorithm is just a math operation, and produces no entropy on its own; a hash digest value contains no more entropy than the amount of entropy that went into its input. If I know that a hash value is the result of running a user's password through a SHA-1 algorithm, as an attacker I don't have to try all $2^{160}$ possible values. I just have to figure out all the values the user might have chosen for a password, and run them through the hash algorithm myself.

Because users are humans, the passwords they choose are frequently based in their native language. If you're guessing the password of an English speaker, it's common to start with a list of frequently chosen English passwords, such as "god", "admin", "root", "password", "abc123", etc, and then move on to testing all the rest of the words in an English dictionary. If a dictionary has 200,000 possible words in it, the entropy is only 18 bits; it takes only a few milliseconds for a computer to compute the hashes of 200,000 words and test each to see if it matches a given hash value.

Note that password restrictions can severely reduce the number of words I would have to test. If a password policy says "passwords must be 6 letters long", then I would first test all six letter dictionary words, which is faster than testing all 200,000 dictionary words. One thing we assume in all cryptosystems is that the attacker knows everything about the system in use, just not the values of the secrets involved.

Check out the wiki page I linked above for a fairly readable introduction to the concepts of entropy.

A good hash doesn't give you any information about password length or anything else. The only attack against such a hash is guessing the password, and then using the hash to verify if it was correct.

Depending on the hashing scheme, the cost per guess can vary widely. For example with plain MD5 a single graphics card can try several billion guesses per second. That's why we use slow schemes, like scrypt, bcrypt or PBKDF2.

• A good hash. But i guess most sites use a bad one, like 95% of them, right? And from a bad hash can you guess about the length? Ps. End a line with two spaces to add a <br/> linebreak: This doesn't work all the time. – superuser Jan 7 '13 at 15:23
• @superuser In this respect pretty much any hash used in practice is good(even MD5). Only really bad homebrew hashes would be vulnerable to that. Using fast hashes or not salting are the two common issues. | PS. you can't use line breaks in comments, only in questions and answers. – CodesInChaos Jan 7 '13 at 15:29