Detecting attempts to decrypt with incorrect secret key in OWASP ESAPI
David Wagner
daw at cs.berkeley.edu
Wed Sep 16 12:52:46 EDT 2009
Advice: if you're creating something for general-purpose use, at a minimum
make sure it provides authentication, integrity, *and* confidentiality.
A reasonable choice might be Encrypt-then-Authenticate where you first
encrypt with AES-CBC, then append a AES-CMAC message authentication
code on the ciphertext (including the IV). As a bonus, this will detect
decrypting with the wrong key.
Use key separation -- with a pseudorandom function -- to derive the
encryption key and authentication key from the master crypto key
supplied by the user: e.g., Encryptkey = AES(K, all-zeros), Authkey =
AES(K, all-ones).
(You could replace AES-CMAC with SHA1-HMAC, but why would you want to?)
(From a cryptotheory point of view, what you want is a mode of operation
that meets IND-CCA2 /\ INT-CTXT, or at least IND-CCA2 /\ INT-PTXT.)
Advice: Provide one mode, and make it secure. Try to avoid
configurability, because then someone will choose a poor configuration.
Suggestion: Provide documentation to warn the programmer against using a
password (or something based on a password) as the crypto key. Provide
support for PBKDF2, with a reasonable default choice of parameters and
appropriate warnings in the documentation, for those who absolutely must
use a password-derived crypto key.
Recommendation: Read the book Practical Cryptography by Ferguson and
Schneier, or at least the chapters on message security. It's the best
source I know to teach you some of the crypto-engineering practicum.
Kevin W. Wall wrote:
>I have considered using an HMAC-SHA1 as a keyless MIC to do this,
>using something like:
>
> MIC = HMAC-SHA1( nonce, IV + secretKey )
>or
> MIC = HMAC-SHA1( nonce, IV + plaintext )
>
>and then also include the random nonce and the MIC itself in the CipherText
>class so it can be validated later by the decrypter, with the understanding
>that the plaintext resulting from the decryption operation should only be
>used if the MIC can be properly validated. (Probably an exception would
>be thrown if the dsig was not valid so there would be no choice.)
I would not recommend either of these. It's better to use a MAC as I
suggest at the top of this email.
Whatever you do, don't choose your second MIC option: if the plaintext
comes from a low-entropy space, it leaks the value of the plaintext
(the plaintext can be recovered by brute-force search over all possible
plaintexts).
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
More information about the cryptography
mailing list