How long does it take to decrypt AES encrypted message with salt(for pbkdf2 key) and iv known

I'm new to crypto!

The situation is,

• Aes-256-cbc encrypted message(including not encrypted iv & salt) is revealed.
• We also know pbkdf2 function uses 10000 rounds with sha256.
• All we need to decrypt the message is just put all the possible passwords in pbkdf2 function with 10000 rounds & sha256,
• and then decrypt encrypted message with those keys with iv & salt revealed.

I tested with js code and single try of above process just takes 2 milli-seconds.

I guess the case of 99% of human-made password will be up to 100,000.

If so, decryption of encrypted message will just take minutes, right?

Did I miss something?

Appreciation in advance!

the case of 99% of human-made password will be up to 100,000

I guess this is intended to mean that 99% of human-made passwords are found within 100,000 attempts. This is way off.

With common-grade passwords, testing the 10⁵ most common passwords is thought to find less than half of them. This is relatively well documented, testable, and can be modeled to a degree by Zipf's law; see this readable blog, or e.g. this.

It's harder to tell the number of passwords to test in order to find 99% of them. If we take the LinkedIn leak as reference, which reportedly was unsalted SHA-1 hashes of user passwords for approximately 117×10⁶ accounts, by this source "only" 60 665 420 of the 61 829 262 unique hashes have been cracked. That is 1-(61 829 262-60 665 420)/117 000 000=99,01% at most of the accounts had their passwords cracked, with enormous effort, which I guess was at least 10¹² passwords tested (I admit I have no reliable way to estimate that number).

decryption of encrypted message will just take minutes, right? Did I miss something?

With common-grade password, the hypothesis of PBKDF2-HMAC-SHA-256 and 10⁴ rounds, and if (as is likely) there is a comparably fast/low cost test of whether the result of PBKDF2 is the correct encryption key, with 10⁵ passwords tested that is 10⁴⁺⁵ HMAC-SHA-256 (twice that many SHA-256), again the probability to find the password is way less than 99%, much closer to 50%, probably less. How much time that takes depends enormously on the resources used. The question reports 5×10⁶ HMAC-SHA-256 per second. But many GPUs can do 10⁸/s. FPGAs and ASICs can raise this tremendously: e.g. this, if it's SHA256d hashing rate was repurposable for HMAC-SHA-256 and encryption key search, would do nearly 10¹⁴/s.

Facts are

• PBKDF2 was already a disputable choice a key stretching function for password-to-key derivation when it was introduced. It has become disastrous with the rise of GPUs, FPGAs and ASICs. Endorsing PBKDF2 is technically unjustifiable, when we now have memory hard functions, like Argon2, that do a much better job of leveraging the (essentially, RAM) resources of a modern CPU.
• 10⁴ rounds of PBKDF2 is now ludicrously low for an encryption application, where key stretching is the primary line of defense (beyond sound choice of passphrase). It was barely enough by 2000 for password protection, where secrecy of the database of hashed password is expected. And by a simplified variant of Moore's law, we should increase the round count by a factor of 10 every 10 years to keep the same security level; and that's far from conservative.