Becoming physically immune to brute-force attacks (2021)

There's an older version of this argument in Schneier's Applied Cryptography (1996). He also concludes that a 256-bit key is secure "until computers are made from something other than matter and consume something other than energy", IIRC.

However, despite things like Ed25519 using 512-bit curve points for 256-bit security (you lose a factor 2 off your exponent because math), this particular instantiation fails much harder if a quantum computer running Shor's algorithm ever becomes reality.

Meanwhile, 123456 still tops the password charts wherever it is allowed.

That's... a much less clever sentiment than it thinks.

> No matter what you say, you will look like a fool

That's because the question is nonsense, not because it's about the future. If the question is "What is the most powerful computer that will be built this decade?" it's answerable. No answer will be correct but there are certainly ways to answer that aren't foolish at all.

Bcrypt does not add entropy, it only adds "difficulty" and the problem with "difficulty" is that it breaks down over time. Improvements in technology and processes routinely undermine the difficulty estimates and corresponding factors used to tune KDFs like bcrypt.

KDFs are good at protecting "okay but not great" passwords used to gain online access, but they add no protection to extremely secure, unique passwords, and they don't add enough protection to extremely weak, common, or reused passwords. They are there to frustrate attacks, not make them physically impossible. Many credentials are time-sensitive, and many attacks are not targeted; KDFs are good in these common situations. You still need to pick a password that will take long enough to crack that an attacker moves on instead.

However, some data needs to be protected practically forever, and some attacks are definitely targeted at specific people or systems. In these cases, KDFs don't do very much. Taking a 256-bit key just from the raw bits of 32 random ASCII letters and numbers will already get you 190 bits of entropy and frustrate all practical attacks for the next several decades at the very least. Feeding that through a KDF first won't add any practical security. Even so, KDFs can be used for a different reason, enabling passphrases, which are long strings with low per-character entropy but high overall entropy. At least, assuming that the KDF preserves that entropy well.

Regardless of bcrypt, you should always pick security keys with sufficient entropy, where "sufficient" is measured relative to the importance of the thing being protected, how long it remains important and accessible by that key, and what attacks are viable now and foreseeable in that time.

Correct me if I'm wrong, but if P is not equal to NP, then we ought to be able to derive as much entropy as we need from a key which is non-brute forceable (at least for symmetric encryption). Eg, if we believe 1024 bits of entropy cannot be brute forced, but our algorithm requires a 4096 bit key to provide at least 512 bits of security against cryptanalysis (plus a margin of safety), then we can derive our larger key from our smaller key without sacrificing any security.

But there's an implicit assumption here that all keys are equally strong, so this doesn't apply to asymmetric encryption. At least not as straightforwardly. And it's possible that P is in fact equal to NP. And there's a bunch of other assumptions here too, like that we really do have a secure source of entropy and really can share keys securely.

Anyway, if we take all these assumptions as read, this suggests that symmetric key lengths will saturate at a certain point (and not much wider than they are today). Big if true.

s/512/1024