# Tag Info

23

If a computer is doing the selection of PIN numbers, then you would be very lucky indeed to guess a PIN in three times. The entropy - assuming that all numbers are valid - is of course $\log_2{10^8} \approx 26.57$ bits. The chances of guessing the PIN correctly in 3 tries is $$1 - \frac{x-1}{x} \cdot \frac{x - 2}{x-1} \cdot \frac{x-3}{x-2} = 1 - \frac{x-3}{... 9 The Bitcoin Bip-39 dictionary with 2048 words can create \approx 2^{263}-entropy by tossing the coin 256 times to choose the words randomly. The random bits are converted into 24 11-bit blocks and every block is mapped into one of the 2048 words by ID. Since the random choice allows repetition, we need n^r not P(n,r);$$2048^{24} \approx 2....

7

The chance to guess right is just $$\frac{3}{10^x}$$ where in your case, $x$ is $8$. You could write it as $$1-\frac {99999999}{100000000}\cdot\frac {99999998}{99999999}\cdot\frac {99999997}{99999998}=1-\frac {99999997}{100000000}=\frac 3{100000000}$$ To simplify it, just imagine a one digit PIN. You have ten possibilities, from 0 to 9. With three tries, ...

6

Well, the best answer I can think of is by referring you to Scott Aaronson's wonderful blog. Quoting the very header of the blog: If you take just one piece of information from this blog: Quantum computers would not solve hard search problems instantaneously by simply trying all the possible solutions at once. So no, a quantum computer would not try ...

6

I don't believe that looking at the diceware phrase is very helpful. Instead, look at it this way; there are $7776^7 \approx 2^{90.47}$ possible 7 word diceware phrases, and diceware will select one of those possibilities uniformly. That means that the probability that one specific phrase is selected is at most $2^{-90.47}$. Or, in other words, if someone ...

6

Users have a habit of choosing passwords badly so that they can be guessed much more easily than cryptographic keys, requiring (say) only a trillion ($10^{12} \approx 2^{40}$) guesses on average instead of a duodecillion ($10^{39} \approx 2^{128}$, or thousand sextillion in the long scale) guesses on average. Users also have a habit of reusing passwords ...

5

Not every company hashes passwords properly and not everyone chooses secure passwords. If you hash them poorly (i.e. if you do not use a password hash with salt, and simply use SHA-256), then you can use a dictionary attack where you hash a list of common passwords and compare them to the leaked hashes and try to find any matches. This way, you can "invert" ...

4

however something that strikes me as counter intuitive is how PBKDF can somehow "stretch" the entropy of a supplied password to generate crypto graphically secure keys. PBKDF2 and other slow KDFs don't increase the actual entropy, but increase its effective entropy. That is, a KDF can make a weaker password with relatively low entropy take as long to attack ...

4

It seems that there are many tools that support strong encryption algorithms, such as AES256, but finding one with a good key stretching function is not so easy. The two standard tools are OpenSSL and GnuPG. However, when it comes to key stretching, OpenSSL 1.1 uses PBKDF2 and GnuPG uses Iterated and Salted S2k, and both are not very resilient to brute-force ...

4

Yes, 7-8 words selected truly at random make a strong password. First we should consider what is a strong password, we measure the strength of a method of generating passwords by how much entropy is in it. The XKCD method https://xkcd.com/936/ uses 4 random commom words and has 44 bits of entropy. This is considered a reasonable compromise if you want a ...

3

Here are a few games we can play: I roll a die 50 times. I write down the results as 1, 2, 3, 4, 5, or 6. You try to guess what I wrote down. I roll a die 50 times. I write down the results as one, two, three, four, five, six. You try to guess what I wrote down. I roll a pair dice, 25 times. I write down the results as 11, 12, …, 16, 21, 22, 23, …, 66. ...

3

Considering quantum computing to break passwords in the online setup would be nonsense. In that setup, passwords are sent to a classical system testing the password. That seems to be the question's scenario. In the offline setup, the information that allows testing if a password is accepted or not is assumed to have leaked to the attacker (e.g. because the ...

3

Password hashing does not increase entropy, no deterministic algorithm can do that. The purpose of a KDF is to increase the difficulty of a brute-force (or dictionary) attack by making the testing of candidate passwords slow. For example, if your passwords are drawn from a distribution with say 48 bits of entropy then with a reasonable computer one could ...

3

Like Ray, I'd like to point out that if the PINs are not chosen randomly but selected by humans and there is no rejection of the easiest pins, the same rules as for passwords apply: some are very, very, very common. This analysis of 4-digit pins shows that 3 tries will allow you to break over 18% of 4-digit pins, not the 0.03% you would expect from the ...

2

If the 256-bit AES key is only used to encrypt the 256-bit password, then I don't think you even need AES at all because a simple OTP can do the work. You may want to use AES if considering a computationally bounded adversary that is able to know some plaintext-ciphertext pairs. OTP has perfect secrecy for one-time use so no adversary (with unlimited ...

2

It kind of makes sense, but there are some hairy details. To use a password as a key you need a password based key derivation function or PBKDF, not just any KDF. Otherwise the adversary can try and guess the password and try to decrypt anything you encrypted with it. Generally that would take just one additional block decrypt, so that's generally a fast ...

2

But the attacker trying to break it as a normal password could assume that it is made up of English words and then they'd know that some letters and combinations of letters are more common. They could try this, but they would be stupid to try this, because there are many fewer $N$-word diceware passwords than $M$-letter strings of English letters of the ...

2

It is my understanding that a KDF adds entropy, whereas a hash loses information. No deterministic process can add entropy. If the same input always produces the same output then the entropy associated with the output cannot be more than the entropy of the input. The confusion probably comes from the practice of using password stretching to compensate for ...

2

The calculation is correct for the given information source. I''m providing a second answer to emphasize that it's only meaningful to talk about the entropy of "information source" - that is mechanism from which data is generated. Since the example given is a rule for creating passwords (insecure ones), it fits to discuss the entropy. Had it been a ...

2

What you're after is fundamentally impossible. Password hashing algorithms are inherently slow. They're designed to be slow even on a computer. Otherwise they would not serve their purpose, which is to make brute force search infeasible. A fast password hash is a broken password hash. You cannot possibly get anywhere near the requisite level of slowness with ...

2

It is likely secure, yes, when it comes to SHA-1. The S2K function, as you mention, simply repeatedly inputs the 8-byte salt and encoded passphrase into the ongoing hash function until a certain number of bytes has been processed (the work factor for this function). Then it produces a key that is smaller than the hash output size. Now this output is an ...

2

For a PIN of length 9, you have exactly 10^9 = 1000000000 combinations (which can be brute-forced by a computer in less than one second). That's 29.9 bits of entropy. For a PIN of at most 9 digits, you have exactly 10^9 + 10^8 + ... + 10^1 = 1111111110 combinations, which is not that greater than the previous answer. That's 30.0 bits of entropy.

2

I think there are two things that are confusing you. Consider sequences of n digits, e.g. 12946, and sequences of n words-for-digits, e.g. one two nine four six. The former have much more entropy per character, in that (for example) the first digit (1) tells you nothing about the second (2) whereas the first letter (o) sometimes completely determines the ...

2

Using the HKDF algorithm would work: prk = HKDF-EXTRACT(salt, master_key) Key1 = HKDF-EXPAND(prk, "info 1", digest_len) Key2 = HKDF-EXPAND(prk, "info 2", digest_len) This creates two keys that are generated from the master key, but given Key1, someone else wouldn't be able to generate Key2, as they don't know the master key.

2

Only randomly generated components matter for passwords/passphrases. 6 randomly generated symbols: lower/uppercase letters and numbers. You have 26+26+10 possible characters, so 62. The entropy of a password is $L\log_{2}N$, where $N$ is the number of possible symbols and $L$ is the number of symbols in the password. So you have $6\log_{2}62=35$ bits ...

1

In terms of English language, what you are asking about are digram frequencies. http://www.viviancook.uk/SpellStats/DigFreqs.html

1

If I want to use this approach, do I have any option other than extracting and storing the bcrypt salt somewhere outside the password field? No. You need to store the bcrypt parameters (salt and iteration count) and the Argon2 parameters.

1

Using crypto_secretstream that should be fine. It generates a random nonce for each message. Reusing a key in that context is fine. Original answer, before edit follows: Yes, that's bad. You have to use a unique IV/nonce for each document. A stream cipher, such as ChaCha, which is combined with the plaintext using XOR reveals the keystream to anyone who ...

1

The simplest solution to this would be to encrypt Bob's pass phrase under Alice's pass phrase. In particular the following steps would be carried out for that: Generate a salted password hash (using e.g. Argon2 or bcrypt) from Alice's pass phrase, call it $SK$ Use $SK$ to encrypt Bob's pass phrase symmetrically, e.g. using AES-GCM If you want to be fancy ...

1

To get "nicer" passwords, whatever that means, the suggestions are typically: … use a selection method but be aware you lose entropy (e.g. pick $1$ out of $16$ passwords at the cost of $4$ bits of entropy) What you are doing is effectively ‘a selection method’ (more commonly known in the literature as rejection sampling) with a bound on the ...

Only top voted, non community-wiki answers of a minimum length are eligible