Detecting attempts to decrypt with incorrect secret key in OWASP ESAPI

[David Wagner]

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