@radium,
Here ya go:
http://www.aescrypt.com/download/v3/linux/aescrack.tgz
Have a look at decrypt.c, and specifically decrypt_optimized(). You can integrate that logic with the generation of passwords you're using to see if a v1 or greater file can be decrypted using the password you try. The v0 file format is different and I didn't do anything to optimize that one. What this function does is load what I call the "session block" from the AES Crypt file and then just try every password guess by running it through the hash functions to see if we can compute the correct hash.
It effectively highlights that the weakest link is the hash function used, though it is SHA-256, so not weak. Nonetheless, on my list of to-dos for the next version of AES Crypt is to strengthen this to where the keyed HMAC is computed over something not visible. Every scheme I've considered so far is weaker than I'd like, though. (Yes, I do spend time thinking of how to brute-force attack encrypted files.) Perhaps I might at least encrypt some data that must be decrypted with a key that must be fed into the HMAC to verify the integrity of the session block. At least then two different function (SHA-256 + AES) are required. I will also likely migrate to an even stronger hash (either SHA-512 or some SHA-3 variant).
I always welcome input. Sadly, I seem to get about as much criticism as constructive input. One complaint, for example, is the 8192 rounds of SHA-256. I've had people express adamantly that it's not enough and I've had other tell me it's pointless. It was suggested to have 100,000 rounds for security. I did tests. The 100,000 rounds adds a little more time, but not so much that it matters. In the worst case, I need 10 computers instead of one to do the same work. That gain is insignificant as I consider that I can fire up 100 or 1000 servers easily. What I want is several orders of magnitude in complexity, but not complexity that would burden the user. It needs to still be fast for those who have the proper key.
