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