Yeah those are the two options, short of actual cryptanalysis. Directly guessing AES keys is always going to be the least effective way as it will have a key space of 2^128 or 2^256 whereas the effective key space of the password is not likely to have this much entropy. Even if the password has more entropy I think brute force on the password will brute force the key in no more time than it takes to brute force the encryption key directly, because of the pigeon hole principle. The KDF can produce outputs of 256 bits, if the password has 300 bits of entropy that means it will take 2^300 guesses to certainly break the password, each password given to the KDF produces a unique output if there are not collisions (there ARE collisions but they should be super rare), by the time you guess 2^256 passwords the KDF should output about 2^256 unique keys exhausting its key space, which means future password inputs can only produce a key output that has already been obtained (there are collisions but they are super rare), which means that you will almost certainly brute force the AES key prior to brute forcing the 300 bit password. On the other hand if you brute force the AES key directly you can guess each key as soon as you generate it, if you use a PBKDF with 100,000 iterations you need to generate 100,000 keys prior to having one for testing (although you could test each key on the path to the one mapping to the password as well). You can calculate the entropy PBKDF iterations add with the following formula: log2(2^password_entropy * pbkdf_iterations) == entropy of password WITH pbkdf iterations so with 10,000 pbkdf iterations an 80 bit password turns into a 96 bits of security, and a 256 bit password turns into 272 bits of security. But with PBKDF or not you are still only guessing 2^256 passwords, it just takes as long to guess that many passwords as it normally would take to guess 2^272 passwords, so actually in this case I think it could be slower to brute force the password than it is to brute force the key directly, unless you guess each of the iterations the password produces when run through the PBKDF all the way up to the final iteration. In cases where a PBKDF is used this is probably the best strategy if you plan to do non stop brute force, because either it will break the key because the password is correct, or it will break the key because it has tried 2^256 unique inputs into a KDF that can only produce 2^256 outputs and which is highly collision resistant. Please correct any of what I just said if I am wrong but I think it is correct, and it pretty much means that it is virtually always best to try to crack the password instead of the AES key directly (because not only is the password likely to be much easier to crack than the key, but even if it is not you will crack the key in the process of trying to crack the much harder to crack password, due to the collision resistance of the KDF and the pigeon hole property). This can be answered easily in millions of hashes per second, when it comes to PBKDF you take millions of hashes per second / PBKDF iterations. I always assume when they give figures about passwords per second that they mean hashes per second unless otherwise specified. Yeah I know TC password is not the same thing as generating a hash, it uses a PBKDF, read my post. I think litecoin tries to be RAM intensive right? That is a cool technique. PBKDF2 (the standard PBKDF and what Truecrypt uses) tries to be CPU intensive.