A tweet-thread (X thread?) by @benwr about how many words you need if you want to use the diceware system to create a password that will be safe for 20 years against 1 year of the whole world's password-cracking capacity. He estimates that 11 diceware words suffices. Content replicated below, with minor editing:

If you care about password strength: you want to measure strength in terms of the min-entropy of the randomized method you use to choose. But how much min-entropy should a password have?

Well, I use a password manager to generate and store ~all of my passwords. I don't care how hard they are to memorize, so I generate crazy-long ones. But there's an important exception: The password for my password manager! How strong does that one need to be?

Important questions: "how long do I want to be safe for?" and "safe against what kind of attacker?". But, if you want to ignore this question and be safe anyway, one option is "I want to be safe for 20 years, against one year of the entire world's cracking capacity."

Let's make some crazy-conservative assumptions:

  1. A cracking attempt can be done with a single floating-point op
  2. N quantum gates can do the equivalent of N^2 floating-point ops worth of password cracking attempts, using Grover's algorithm
  3. compute doubles every year

Globally < ~10^24 = 2^80 classical ops/s. Quantum gates is harder to estimate, but I think currently less than 10^8 = 2^27 gates/s. If both double yearly, classical will dominate for about 15 years. But since we want 20 years of security, we care more about quantum.

2^27 gates/s doubled for 20 years gives 2^47 gates/s. pi seconds is a nanocentury: 3.15e7 seconds in a year, so[, since 3.15e7 = 30 * 10^6 = 2^5 * 2^20 = 2^25], 2^25 * 2^47 = 2^72 gates/year. Double that (quantum, remember?) to get 144 bits of cracking capacity. ~11 diceware words. Not impossible to remember!

Estimates of global classical compute:

Estimate of global quantum compute is based on this table

plus this estimate of gates/s for a single machine

Compute doubling yearly is a wild and crazy number I made up to be way too fast

Diceware

Addendum: Every additional diceware word you add should increase the timeframe by about 6 years

New Comment
6 comments, sorted by Click to highlight new comments since: Today at 8:24 AM

You might want to add a single nonstandard Unicode character at a random position to get a lot of additional entropy.

maybe; probably the easiest way to do this is to choose a random 4-digit hexadecimal number, which gives you 16 bits when you enter it (e.g. via ctrl+u on linux). But personally I think I'd usually rather just enter those hex digits directly, for the same entropy minus a keystroke. Or, even better, maybe just type a random 3-character base32 string for one fewer bit.

If you have a nonstandard unicode character in your password and an attacker tries to crack a password based on the assumption that no nonstandard unicode character is in the password, they can't crack your password no matter how much compute they throw at it.

Given that you decide where in your string you place it, the attacker would have to test for the special character being at multiple different positions which adds a lot of additional entropy.

Well, not that much, right? If you had an 11-word diceware passphrase to start, each word is about 7 characters on average, so you have maybe 90 places to insert a token - only 6.5 extra bits come from choosing a place to insert your character. And of course you get the same added entropy from inserting a random 3 base32 chars at a random location.

Happy to grant that a cracker assuming no unicode won't be able to crack your password, but if that's your goal then it might be a bad idea to post about your strategy on the public internet ;)

If you have a nonstandard unicode character in your password and an attacker tries to crack a password based on the assumption that no nonstandard unicode character is in the password, they can't crack your password no matter how much compute they throw at it.

Given that you decide where in your string you place it, the attacker would have to test for the special character being at multiple different positions which adds a lot of additional entropy.