Detecting attempts to decrypt with incorrect secret key in OWASP ESAPI

Joseph Ashwood ashwood at msn.com
Wed Sep 16 19:11:22 EDT 2009


--------------------------------------------------
From: "Kevin W. Wall" <kevin.w.wall at gmail.com>
Subject: Detecting attempts to decrypt with incorrect secret key in OWASP 
ESAPI


> The new default for the new encryption / decryption methods is to be
> 128-bit AES/CBC/PKCS5Padding and use of a random IV.

That's a good solution, except for the missing MAC, considering the 
environment I would suggest hard coding it, there's really no reason to 
offer options.


> MIC = HMAC-SHA1( nonce, IV + secretKey )
> or
> MIC = HMAC-SHA1( nonce, IV + plaintext )
> MIC = HMAC-SHA1( IV, plaintext )
> So, having provided all of that background, in summary, here are my
> three questions:
>    1) Is using either of these MIC calculations cryptographically secure?
>    2) If answer to #1, is 'yes', which one is "safer" / more secure?
>    3) If answer to #1 is 'no', do you have any suggestions less
>       computationally expensive then digital signatures that would
>       allow us to detect attempts to decrypt with the incorrect secret
>       key and/or an adversary attempting to alter the IV prior to the
>       decryption.

You are looking at the correct type of construct, the solution for your 
problem is known as a Message Authentication Code or MAC. The biggest 
concerns are what are you MACing, and that it must use a second key. There 
are a number of solutions.

The first part of the solution is to store an additional key, you're storing 
128-bits hopefully securely store 256, and split it, trust me you'll thank 
yourself when the security issues are investigated. The second key is for 
the MAC algorithm.

Since you already have CBC available, my first suggestion would be CBC-MAC 
(IV = 0x0000000, okcs5 padding works fine, MAC = final block of ciphertext), 
it has good strong security proofs behind it, and is fast. Apply the MAC 
algorithm, prepend the MAC value to the plaintext (just because indexing is 
easier this way), then encrypt to ciphertext, store. To decrypt, retrieve, 
decrypt the ciphertext, parse out the MAC value and the plaintext, run MAC 
algorithm on plaintext to find MAC2, check MAC == MAC2 . This will give you 
a failure rate of 1/2^128 or something on the order of 
0.0000000000000000000000000000000000003%, you are more likely to have the 
system burst into flame than see a false positive on this. Overall, this 
will reduce your speed to 50% of the current.

You might also want to take a look at Poly1305, it is faster.

As you noted HMAC is also available, but I would recommend against using 
SHA-1 for anything, it simply raises too many questions that will take too 
long to answer. The secure hashes available are simply not as fast unless 
you have bare-metal coding ability which Java really doesn't like.

The other, and arguably better, option would be a combined mode. The good 
combined modes are a legal minefield, so using them for an open project is 
difficult. It is claimed that GCM and EAX are public domain, but I'm more 
inclined to recommend the conservative approach and avoid them.

While there has been no concern raised by cryptanalysts about CBC with 
CBC-MAC, to many laypeople it doesn't look good. So, for purely politic 
reasons, I'm recommending the shift to CCM mode. At the same time I 
recommend moving to an IV counter instead of random IV, in CTR mode it is 
necessary to make sure an IV is never reused and randomness is irrelevant. 
This will give you a thoroughly analyzed standard mode of operation.
                    Joe 

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com



More information about the cryptography mailing list