Re: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01

["Manger, James H" <[e-mail]>]

There are two risks:

1.       The CBC padding is processed before the MAC is verified

2.       The plaintext is used before the MAC is verified

The draft could make the CBC padding processing even safer by being even more lenient: only consider the least significant 4 bits of the last byte (ie modulo the block length). That is guaranteed to be in [0,15] so it always gives a valid padding length (0 means 16 bytes of padding). Such padding processing can never fail so it can never act as a padding oracle even if it is accidentally performed before the proper MAC integrity check.

Mind you, I would expect many implementations to use existing implementations for the padding that will not be changed to be lenient. Hence the Security Considerations should say that it is crucial that the MAC is verified before the CBC padding is processed.


If you operate in a streaming mode (ie you don’t want to buffer the whole ciphertext before outputting anything) then corrupted plaintext can be produced, and a MAC failure will only be reported later (or never, if the end of the ciphertext is never received). draft-mcgrew-aead-aes-cbc-hmac-sha2-01 “prevents” this by performing the MAC verification (step 3) before the decryption (step 4), but that ordering will be ignored by APIs that support streaming.

In Java, for instance, the Cipher class has an update(ByteBuffer input, ByteBuffer output) methods that can be called any number of times (outputting plaintext) before calling doFinal(...), at which point an exception is thrown if the integrity check fails. As an example, the BouncyCastle implementation of AES/GCM/NoPadding decryption returns plaintext from the update(...) calls; it does not buffer the plaintext until the integrity check in the doFinal(...) call.

The Security Considerations section hints at this issue by talking about a “single atomic operation”:
   There are security benefits to providing both confidentiality and
   authentication in a single atomic operation, as done in this note.
   This tight binding prevents subtle attacks such as the padding oracle
   attack.
Perhaps add that “while a streaming implementation of decryption can calculate some plaintext before all the ciphertext has been processed, the authenticity is not ensured until all the ciphertext has been processed”.


--
James Manger



·         Section 2.2, step 3. When MAC verification fails, the draft recommends halting the operation before CBC decryption. We have seen timing and error-code based attacks against TLS’ MAC-then-Encrypt scheme. I realize that the draft is prescribing E-t-M. Nonetheless, considering a potential flaw in HMAC-SHA2 series (I don’t know of any, but …), I’d suggest not halting the operation even after MAC check fails, but continuing on to CBC decryption, and then returning an error that doesn’t distinguish between a MAC and a decryption (pad check) error. Yes, this would consume more CPU cycles only to waste them *under an attack*, which is not necessarily bad.

Your suggestion aims to hide from an attacker whether or not the authentication check passed or failed, by removing the (significant) timing difference in whether decryption is performed or not.  I don't see what security advantage this provides.   In many scenarios an attacker could tell whether or not a message was accepted anyway, by observing that the receiver acted on that message.


·         Section 2.2, step 5. Unspecified error case of invalid padding (link to my comment above).

The draft does consider invalid padding, and takes a conservative in what you send, liberal in what you accept policy.   The sender is required to use PKCS/PEM style padding, but the receiver is only told to consider the final octet of the padding (which is the only octet that matters).   The Step you mention says:

                                                                           If the final octet has
       a value outside that range, then all of the data used in the
       processing of the message is zeroized and discarded, and the AEAD
       decryption operation returns an indication that it failed, and
       the operation halts.

This could be amended by saying that "If the padding string does not have the form described in Step 3, the message MAY be rejected".

I think that the liberal-in-what-you-accept policy is the best option here, but I could be convinced otherwise.   The citations for padding schemes mentioned earlier are silent on this issue.

David