> 44 bits of randomness might be feasible for a serious attacker, while maybe if it was 1000 times harder they'd give up My back-of-the-napkin math[^1] says th

> 44 bits of randomness might be feasible for a serious attacker, while maybe if it was 1000 times harder they'd give up 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 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