> If you divide your key search effort by 10 your chances of success are divided by 10 (linear drop off).

Right, but if the starting point is 128 bits it doesn't matter how much you can parallelize the attack, you're not going to find a key regardless of how you divide the key space, even if the chances drop off only linearly.

Again, this is about "good enough". 128 bits of collision security are "better" than 128 bits of "preimage security" (I've never heard resistance against encryption key brute force called preimage security, but I think I get it) in the same way that 256 bits of collision security are better than 128 bits of collision security, or any bigger number is better than a smaller number. Cryptography needs to be secure, not as big as possible.

> Right, but if the starting point is 128 bits it doesn't matter how much you can parallelize the attack, you're not going to find a key regardless of how you divide the key space, even if the chances drop off only linearly.

If you combine a parallel attack with a scaled down search, a standard parallel attack can give a state-level attacker chances comparable to the lottery. Very low, just not quite impossible. Enough to protect your wallet, or even your life, perhaps a tad low to protect something like Wikileaks. (Perhaps. the US has shown they have other means.)

> I've never heard resistance against encryption key brute force called preimage security

I'm trying to coin the term, for lack of anything better. As far as I am aware there are two broad classes. One includes key searches and hash preimage attacks. The other includes hash collisions and discrete logarithm problem (without the help of index calculus).

If you have a better term for key search/preimage attack that is more readily understood by readers I would try to use that instead.

> any bigger number is better than a smaller number.

Sure, the choice is what threshold we might use. To do this it might help to get an upper bound. I've read an article stating that a perfect computer operating at space temperature would require the energy of something between a nova and a supernova to explore all the configurations of 256 bits. This is more than the entire output of our sun, so we know that there's no point in ever going higher.

On the lower bound section we have the number of hashes performed by the Bitcoin network. Their peak right now seems to be around 370 Exa-hashes per second, or about 2^93 hashes per year. It thus seems reasonable to never go below 93 bits of security (of any kind).

We can debate the exact numbers. My feeling is that anything above 192 bits is high enough to be utterly boring, and anything below 100 bits is too low for anything high stakes. Between the two however I'm forced to agree with you: any bigger number is better than a smaller number.

>...about 2^93 hashes per year.

128-93=35 bits. 2^35=34 billion years which is significantly longer than the age of the universe. That seems to support the contention that 128 bits is simply not brute forceable at the chances of a lottery or at all.

100-93=7 bits. 2^7=128 years. So 100 might be a bit high for a reasonable lower bound, but is at at least reasonable assuming some sort of breakthrough in computing.

Crap, good catch… I somehow managed to pretend 2^35 = 35. Oops.

That being said, one chance in 34 billion is only 3 orders of magnitude from typical lotteries, and in settings where multi-key attacks are applicable (not Age), we can definitely achieve lottery levels of success (with 1000 keys we get down to 1 in a 34 million chances for 1 year). 100 bits looks too low: in 1 year chances of success on a single key go up to 0.8%. That's pretty high.

We also need to keep in mind the actual algorithm used. When it's SHA-256 and Chacha20 we can say it's pretty comparable to Bitcoin, though there might be a small factor difference between hashing a full block and trying a key in a file. But if the entire path involves more hardware friendly primitives like AES, dedicated silicon could be quite a bit more efficient than the Bitcoin network currently is, and would drive down the costs (or drive up the chances of success) accordingly.

Now, do I actually believe a state level attacker would construct something as powerful as the entire Bitcoin network just so they have an extremely slim chance of cracking one key among many after years of burning energy over the search? No. 128-bit keys are safe, even in the face of multi-user attacks.

But the reasoning required to arrive to this conclusion is more complex than the one needed to assert that 256-bit keys are safe, because "there's still a chance". It's not plausible at all, but it remains humanly possible. With 256-bit keys we know it's flat out impossible. With 256-bit keys we don't even need to think, and that alone has some value.

I think boring-ness is the crux of it, for me.

From what I've understood, 128-bits is fine-in-practice, unless you're an extremely high-value target who is also feeling unlucky. Even if I was a whistleblower under an authoritarian regime, I'd feel pretty safe using Age in its current form (at the very least, I'd have bigger things to worry about).

However, it's not quite boring enough - the fact that this conversation is happening at all attests to that fact. It would cost almost nothing to increase file key size to 256 bits, and so IMHO it should be considered for an "age v2" - but at the same time, not something people should be alarmed about in the current implementation. (with the caveat that I'm not exactly qualified to make that assertion)

> IMHO it should be considered for an "age v2"

Definitely, though personally I wouldn't go as far as recommend we make a version 2 just for this. The downsides of such a change are not worth the arguably extremely slim security benefit.

(And I agree with Age author it's not worth warning users about either. Not now in 2023.)

Right. I don't think this is a reason alone to make breaking changes, but if a new version is coming out for whatever reason(s), it should be bundled in with the other changes.