The gist of which (as I understand) is that the component itself not really capable, or intended to do so. Which if you think about it kinda makes sense, if the component could so easily return a pass fail for each attempt it would make a brute force attack just a little bit easier... right?

What I did not see in the answer for the above question was a possible solution, but I've thought about it myself and I can think of several ways to work around this. If you are decrypting an unknown file type you can check the beginning of the file against a list of header data from known filetypes. If your application is the one doing the encryption, you can pair each encryption with a small data file whose output is known and run each decryption against that first to verify the password. This gives you your pass/fail and you don't have to bother with the file if the password fails. You could probably do that in several ways, store the data file in a db, or even prepend the encrypted bytes to the encrypted file (if it moves around and a db is not accessible). If all your settings are the same for the CK component and the cleartext of your known data sample is always of the same length, then you would always produce the same number of bytes regardless of password used. So you can just separate that many bytes from the file and decrypt them independently.

That's just what comes to mind, I'm sure people have worked out lots of ways of addressing this, as it is a limitation (byproduct really) of the process and not the CK components. You could probably find all kinds of workarounds with a little googling :)

The reason I ask is because I used to use a COM Component in the old days called RSP Encrypt, it could detect a CRC error, this same error would also apply if the user entered the wrong password. So all I did when I it got an error of type CRC Error, I would tell the user that it was a CRC error and to check the password.
And it did have to decrypt the entire file, before it knew it was an CRC error. That's not a problem.