Caveat: I can't think of an application I've done where I consider
rapid wrong-key detection a feature I want. Usually, I'm perfectly
happy for that to take as long as I can feasibly make it take. The
faster I tell someone about an incorrect key, the faster they can
brute-force my real key, as far as I see it.

That said, If I wanted to rapidly detect a wrong key, I'd concoct some
known or agreed-upon value, and use the password-derived decryption
key (or a hash thereof if it's too long to use directly) as the key
for an HMAC over the known or agreed-upon value. I'd store that with
the file and calculate it prior to attempting to decrypt the file to
see if my decryption key was valid.[1]

But let me reiterate... slow discovery of an invalid decryption key
sounds more like a feature than a bug to me, so I'd think very
carefully before implementing this kind of scheme. I suspect that this
is why you can't find the answer. Why do you want to make it faster to
attack your encryption scheme?

Geoff

[1] An authenticated mode like GCM might achieve the same goal here.
I'm not sure. My instinct is that this application would be an abuse
of such a mode and would provide neither security nor performance
advantages over what I describe, but I haven't spent much time
studying authenticated modes and could definitely be wrong about that
assertion.

On Mon, Apr 4, 2011 at 09:47, Ahewd.com <[email protected]> wrote:
> I have an application which encrypts a file with AES in CBC mode,
> using a password entered by user to generate a key. I'm using
> FileSource with StreamTransformationFilter to do the job.
> The problem is that if the user enters wrong password and decrypts the
> file, FileSource bombs out (after the whole file is decrypted) with
> exception: "StreamTransformationFilter: invalid PKCS #7 block padding
> found".
>
> What's the correct method to detect that a file to decrypt was
> encrypted with a different key? Is it safe to catch that exception for
> this purpose? I need to notify the user that the password entered is
> wrong.
> Ideally, this would have to be done without first having to decrypt
> the entire file, which may take a long time when the file is large.
>
> This question must already have been asked many times but i can't find
> the answer...
>
> --
> You received this message because you are subscribed to the "Crypto++ Users" 
> Google Group.
> To unsubscribe, send an email to [email protected].
> More information about Crypto++ and this group is available at 
> http://www.cryptopp.com.

-- 
You received this message because you are subscribed to the "Crypto++ Users" 
Google Group.
To unsubscribe, send an email to [email protected].
More information about Crypto++ and this group is available at 
http://www.cryptopp.com.

Reply via email to