From: "Kevin W. Wall" <kevin.w.w...@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 )
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

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 majord...@metzdowd.com

Reply via email to