They're "the same cost" because anyone with account to $1M or $1B to break a cert generally also has access to $2M or $2B. No reasonable threat model includes defending against attackers that have 50% of the necessary capital to conduct an attack but not more.
Objection! There is one such threat model: content protection schemes (like BD+) are that finely-calibrated. The goal is to be secure enough for the new release window, but to accept failure after that point.
You're totally right here, I'm just nerding out on threat models and security economics.
I think this is a general fallacy held by a lot people.
The notion that someone who has access to X amount of funds for a given task automatically has 2X and can also afford to spend 2X on the given task is not necessarily true, so such claims are generally baseless.
What is most interesting is that these claims are generally about non-exact amounts, so the logic should follow that if you can afford X, then you can afford 2X, also means that you can afford 4X, and 8X, ad infinitum.
In practice, a 2X difference in majority of real life cases concerning substantial amount of resources is by definition substantial and far from a trivial.
I'm not sure but I think you're trying to say I'm wrong. In the general case it's wrong, of course, to say that being able to afford X implies being able to afford 2X: few people could afford 2x their rent or a house 2x the price of theirs, etc. Few people would fail to be meaningfully affected by getting 2x (or 1/2x) their salary.
But I'm talking specifically about cryptographic threat models. No reasonable threat model says, conducting this attack takes $100,000, and since most people don't have $100,000 in savings it's safe, because defending against "most people" isn't meaningful. A reasonable threat model says either, conducting this attack takes $100,000 so we're going to add an additional layer of security because it's a realistic attack, or conducting this attack takes $100,000,000,000,000. In such a threat model, if the numbers change by a factor of two in either direction (either through a one-bit error like this, or through macroeconomic trends, or whatever), it doesn't change the analysis.
And in particular the claims here are in fact about exact amounts: a factor of two, or one bit. Cryptographers tend to measure things very precisely in bits. There's usually no good reason for a particular choice (64 is not a magic number here, it's just a convenient number for computers), but the analysis is still done with that particular choice. You can measure the difficulty of attacking a problem with N bits of entropy, and then add a heavy margin on top, and be very clear about what that margin is. Once you've done that, N-1 becomes probably reasonable, and you can argue precisely about why it's reasonable; you can argue equally precisely that N-5 is questionable and N-10 is not reasonable, and that the arguments are not recursive.
> No reasonable threat model says, conducting this attack takes $100,000, and since most people don't have $100,000 in savings it's safe
Sure, that is never the claim.
> And in particular the claims here are in fact about exact amounts: a factor of two
Sure, but that is still a factor of X, an unknown amount.
The bottom line is that for many actors, even nation state, the cost difference of 20M and 40M might mean that they have to seek alternative options. Not every actor has access to infinite amount of USD or compute.
And my claim is that if your threat model depends on an attacker who can afford $20M being unable to afford $40M, your threat model is flawed and you've already lost. They might have to seek alternative options. They might not. They might just be able to issue $20M of bonds, who knows. They might have a strong economy next year and the attackerbucks-to-USD exchange rate might double. If you need to defend against an attacker with $30M in the bank, make the attack cost $30B or $30T.
And the neat thing about crypto is that's easy to do: just increase the amount of entropy involved. A mere ten more bits make a brute-force attack cost 1000x as much. If we're genuinely worried that 63 bits is too small, ditch the 64-bit requirement and make it 128-bit. (Probably phrase it as 120-bit, so people can use UUIDs and whatnot - the point is still that 120 is still clearly more than enough, not near the borderline.)