Earlier quoted context omitted.
You’re assuming the key is 256 random bits, which is almost certainly untrue for a human-rememberable password. The 16 bytes of salt are public, and AES is designed to be _fast_, so this scheme is horribly insecure for password-based security.
It doesn't need to be 256 random bits. The chosen design smears the key, so if your password has 10 bits of randomness, my best attack is to try those 10 bits worth of passwords. That is practical to try, but if I have enough bits you might as well just guess keys, which you can't do, so, game over. It does need to be actual randomness, so "NameOfCorp" won't work to protect Corp's documents, but people need to get ov…
My back-of-the-napkin math[^1] says that, on an AMD Ryzen 7 1800X (released in 2017), brute-forcing 54 bits of entropy in AES-256-GCM takes an average of about 2.6 months. That’s on (pretty outdated) consumer hardware, not GPUs, specialized ASICs, or parallelizing across different machines. That’s considered outrageously insecure in the infosec world - anyone with a few thousand dollars to spare on cloud computing can crack.
> a fancy stretching algorithm won't make terrible passwords good
A properly tuned password-hashing algorithm like Argon2 should take about 1 second per hash, and can be configured to eat as many cores and memory as you expect the attacker to have/you feel like dedicating to hashing. Let’s assume you dedicate 2 cores to each hash (a relatively conservative value) - that same 54 bits of entropy now takes an average of 71 million years to crack[^2]. You’d literally be better off trying to brute-force the full AES-256 key space, after the key derivation step (which is the whole point of Argon2 and similar algorithms).
Dangerous advice like you’ve just spouted is against every single password hashing guideline out there - please trust the cryptographic community, they do in fact know what they’re doing when designing algorithms (or at least they know better than you).
[^1]: 2642 MBps per core (https://calomel.org/aesni_ssl_performance.html) = 165 million 128-bit blocks per second per core = 1.32 billion 128-bit blocks per second -> 6.82 million seconds to try 2^53 combinations (50% chance of success) = roughly 2.6 months
[^2]: 1 hash per second per 2 cores = 4 hashes per second -> 2.25e15 seconds to try 2^53 combinations = 71 million years