3 ms·

> 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

> 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.

loup-vaillant 4y ago
> 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.
- Retr0id 4y ago
  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)
  - loup-vaillant 4y ago
    > 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.)
    - Retr0id 4y ago
      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.
- upofadown 4y ago
  >...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.
  - loup-vaillant 4y ago

loup-vaillant 4y ago

> 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.

Retr0id 4y ago
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)
- loup-vaillant 4y ago
  > 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.)
  - Retr0id 4y ago
    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.
upofadown 4y ago
>...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.
- loup-vaillant 4y ago