[aborsy]

I don’t know why the author likes AES 128 so badly. AES 256 adds little additional cost, and protects against store now decrypt later attacks (and situations like: “my opinion suddenly changed in few months”). The industry standard and general recommendation for quantum resistant symmetric encryption is using 256 bit keys, so just follow that. Every time he comes up with all sorts of arguments that AES 128 is good.

Age should be using 256 bit file keys, and default to PC keys in asymmetric mode.

[FiloSottile]

> The industry standard and general recommendation for quantum resistant symmetric encryption is using 256 bit keys

It simply is not. NIST and BSI specifically recommend all of AES-128, AES-196, and AES-256 in their post-quantum guidance. All of my industry peers I have discussed this with agree that AES-128 is fine for post-quantum security. It's a LinkedIn meme at best, and a harmful one at that.

My opinion changed on the timeline of CRQC. There is no timeline in which CRQC are theorized to become a threat to symmetric encryption.

[cwmma]

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.

[lucb1e]

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]

Because you cannot "just literally replace those 3 characters and be done with the upgrade".

[lucb1e]

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]

The moment you say "lot of cases", multiply the cost by $100,000,000.

[lucb1e]

lol, sure

[brohee]

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

[aborsy]

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.