4 ms·

he pretty explicitly states that AES 128 is not in any imminent danger and mandating a switch to 256 would distract from the actual thing he thinks needs to hap

by cwmma 6mo ago

he pretty explicitly states that AES 128 is not in any imminent danger and mandating a switch to 256 would distract from the actual thing he thinks needs to happen.

aborsy 6mo ago
How would he know? Did he publish papers on it? You can’t just throw “Grover’s algorithm is difficult to parallelize” etc. It’s not same as implementation, especially when it gets to quantum computers. It’s very specialized.
lucb1e 6mo ago
So why argue about whether AES-256 is worth it if we can just literally replace those 3 characters and be done with the upgrade? This was the smart move already in 2001 when Shor's algorithm was known and computers fast enough that we don't notice the difference. At least to me, it seems like less bikeshedding will be done if we abandon AES-128 and don't have to deal with all the people left wondering if that's truly ok Then again, something something md5. 'Just replace those bytes with sha256()' is apparently also hard. But it's a lot easier than digging into different scenarios under which md5 might still be fine and accepting that use-case, even if only for new deployments
- tptacek 6mo ago
  Because you cannot "just literally replace those 3 characters and be done with the upgrade".
  - lucb1e 6mo ago
    That would depend... There's a whole lot of cases where the tokens are temporary in nature with an easy cut-over, either dropping old entries or re-encrypting while people are not at work. We tend to think of big commerce like amazon or google that need 24/7 uptime, but most individual systems are not of that scale In most other cases you increment the version number for the new data format and copy-paste the (d)e(n)cryption code for each branch of the if statement, substituting 128 for 256. That's still a trivial change to substitute one algorithm for another Only if there exists no upgrade path in the first place, you have a big problem upgrading the rest of your cryptography anyway and here it's worth evaluating per-case whether the situation is considered vulnerable before doing a backwards-incompatible change. Just like how people are (still) dealing with md5
    - tptacek 6mo ago
      The moment you say "lot of cases", multiply the cost by $100,000,000.
      - lucb1e 6mo ago
        lol, sure
- brohee 6mo ago
  I'm working on just that in some IoT context, and a lots of chips I have to deal with only have hardware support for AES-128, so it's a little more complicated...

by cwmma 6mo ago

he pretty explicitly states that AES 128 is not in any imminent danger and mandating a switch to 256 would distract from the actual thing he thinks needs to happen.

aborsy 6mo ago

How would he know? Did he publish papers on it? You can’t just throw “Grover’s algorithm is difficult to parallelize” etc. It’s not same as implementation, especially when it gets to quantum computers. It’s very specialized.

lucb1e 6mo ago

So why argue about whether AES-256 is worth it if we can just literally replace those 3 characters and be done with the upgrade? This was the smart move already in 2001 when Shor's algorithm was known and computers fast enough that we don't notice the difference. At least to me, it seems like less bikeshedding will be done if we abandon AES-128 and don't have to deal with all the people left wondering if that's truly ok Then again, something something md5. 'Just replace those bytes with sha256()' is apparently also hard. But it's a lot easier than digging into different scenarios under which md5 might still be fine and accepting that use-case, even if only for new deployments

tptacek 6mo ago
Because you cannot "just literally replace those 3 characters and be done with the upgrade".
- lucb1e 6mo ago
  That would depend... There's a whole lot of cases where the tokens are temporary in nature with an easy cut-over, either dropping old entries or re-encrypting while people are not at work. We tend to think of big commerce like amazon or google that need 24/7 uptime, but most individual systems are not of that scale In most other cases you increment the version number for the new data format and copy-paste the (d)e(n)cryption code for each branch of the if statement, substituting 128 for 256. That's still a trivial change to substitute one algorithm for another Only if there exists no upgrade path in the first place, you have a big problem upgrading the rest of your cryptography anyway and here it's worth evaluating per-case whether the situation is considered vulnerable before doing a backwards-incompatible change. Just like how people are (still) dealing with md5
  - tptacek 6mo ago
    The moment you say "lot of cases", multiply the cost by $100,000,000.
    - lucb1e 6mo ago
      lol, sure
brohee 6mo ago
I'm working on just that in some IoT context, and a lots of chips I have to deal with only have hardware support for AES-128, so it's a little more complicated...